I would like to request support for a new subdirectory under /custom that is always added to sys.path by every Deadline application. For example:
<RepositoryRoot>
` custom
|- events
|- plugins
|- python # Always on sys.path
`- scripts
For a little background, because Deadline does not support external search paths for scripts, plugins, etc, we keep all of the things that are deployed to the Deadline repository’s custom subdirectory in their own git repository. I would simply like to be able to store reusable code for the custom scripts and plugins alongside them in a way that it can be automatically detected. I want to avoid using the existing “Python Settings” in the repository options , since that only further obfuscates things by hiding part of the discovery process.
i think this is a useful ideal, but please make sure to include a python version subdir type system.
Not all dcc’s or dcc’s in our pipeline use python2.7 yet, so needing to segregate versions/binaries would be super useful.
nrusch what we did to work around this in our pipe is we have an extra python file in all the plugins that is called:
JobPreLoad.py
This one file is the same for all the plugins to call a method in out python code structure that sets up the paths needed for a job.
docs: docs.thinkboxsoftware.com/produc … preload-py
in this case you could make your own python folder at that level and make it so the jobpreload.py appends the path if it is not already in the path.
Well, the scripts in the repository are for use by Deadline, not DCCs.
I think you may have misunderstood my request somewhat. I’m looking for a place to put reusable modules that is always automatically on sys.path in Deadline applications and can be shared across custom application scripts, event listeners, and job plugins. JobPreLoad.py only works for one of those categories (and is not a module), and copying the same file into every plugin directory is pretty antithetical to reusing code.
I wonder if you could use the newish “pythonsync” system which we use to distribute/sync/cache down to the local clients any 3rd party py modules/scripts? (See the “pythonsync” directory in your repo root) Before I shoot my mouth off, I will check with the team we are willing to support this for end-user usage.
Pythonsync is a bit more annoying, since it’s a zip file.
We already have a list of paths that we add to the sys.path as part of the Repository Configuration (see:http://docs.thinkboxsoftware.com/products/deadline/9.0/1_User%20Manual/manual/repository-config.html#python-settings). Those paths should be path-mapped and applied to every Deadline Client applications that uses embedded Python. The thing this does not do though, is allow definitions relative to the Repository path, which I think would be easy enough to add.
That said, we could ourselves make good use of something like you describe, so we might very well end up doing both
Not to put too fine a point on it, but I’m definitely not interested in having deployed custom code redeployed via a system I can’t see or control.
Sorry, I’m going to be stubborn… I really want to avoid setting up a static path in the repository options. Whether said paths are absolute or relative to the repository wouldn’t change the fact that that system adds a hidden configuration step that has to be documented separately by the end user.
I’m really just looking for another directory inside /custom that I can put Python packages and modules in, that isn’t treated in any special way except always being added to sys.path, in the same way that all of the current subdirectories of <REPO>/custom/scripts are always used the same way to discover contextual scripts. Also, because it would be a feature of Deadline, it would be documented by Deadline.
Nothing would force end users to put anything there (just like they aren’t forced to write custom scripts if they don’t want to), but for those who just want a zero-configuration method of deploying custom modules alongside custom scripts, it would be quite useful (until Deadline supports sourcing custom scripts and plugins from outside the repository, that is…).
