AWS Thinkbox Discussion Forums

Opensourcing Plugins

Would it make sense to host all of the deadline plugins on something like bitbucket or github? It might make forking and minor studio changes easier if there is an official repository. Thoughts?

1 Like

I don’t really see how this would make anything easier, especially since Deadline has no way to override/redirect or extend the repository’s plugin search path. Seems like it would be easier for you to just initialize an hg/git repo in your Deadline repository’s ‘plugins’ directory.

So we actually added the ‘custom’ folder in the repo for this exact purpose :slight_smile:. The monitor/slave should always look there first, and it won’t get wiped by upgrades!

With regards to open-sourcing scripts, it might be something we’d look at in the future, but for right now I think we’ll leave them as-is. If you want to keep up with our changes as we do releases, it shouldn’t be too hard to use a diff tool (like WinMerge or something) to pop changes over into your custom versions whenever you upgrade your repo.

Cheers,

  • Jon

Interesting. I guess I missed that in the release notes. Does this mean the custom directory will squash out any base plugins with colliding names?

Yeah, if you have a ‘Nuke’ plugin folder in both ‘plugins’ and ‘custom/plugins’, the Slaves will always use the one from ‘custom/plugins’, and ignore the one we ship in the root ‘plugins’ folder.

You can set per-Job plugin folder overrides (under ‘Job Properties’ -> ‘Environment’), which is meant mainly for testing changes/new plugins before rolling them out to the farm.

I don’t know how other people think about this new setup, but for me it’s a huge win for studio specific customisations, which we each have to deal with in our studios!
The great thing for me, is that I can keep up to date with minor Deadline upgrades a lot quicker than before in our production repository and not have to worry to much :slight_smile:

Yeah, this is definitely a step in the right direction. I’ll probably continue to use stub plugin loaders until the plugin load path can be customized (so the body of the plugin classes is still in our pipeline repository), but it’s good to know I can re-use the names of the built-in plugins.

Thanks for the info Jon.

A common repo would help in merging customized code with official updates, not just simplify the rollout. Currently every update i do, i spend about 30-40 minutes merging official updates with our customizations, with a simple git update, it would be a matter of seconds :slight_smile:

cheers,
laszlo

Yeah that’s what I was thinking too. It could also speed up little fixes and update so that we wouldn’t have to install a new build of deadline just to merge an update to the max py file for instance. If I forked the Nuke plugin then when you update the nuke plugin I could just merge and auto-dif your new additions.

Good point. And it could also allow people to submit patches to add functionality, clean things up, fix issues, etc.

Hey there, sorry for necro-posting, but any chance (now that you are with AWS, I know they do Open Source stuff) you changed your mind on this? Maybe you could do like Epic Games, and only allow certain github accounts (ie paying customers) to join the repo?

Or at the very least, could you guys provide a separate download (a .zip) with the DeadlineRepository10/plugins and the DeadlineRepository10/submission (without the installers) ? Or change the installer to allow extracting those folders?

I think is not reasonable to force people to re-install a whole Deadline (+ mongodb) just to get the updates?

Yes, in an ideal world, we would be using the custom folder and everything would be version controlled, but we all know how this industry is, and I don’t believe this is such an insane request (neither the github or the zip).

Thanks for your time.

Privacy | Site terms | Cookie preferences