Hello all,
I have a general question about Deadline’s software structure in terms of accessing libraries. Does Deadline use the Python libraries that you have installed locally on the “worker/slave” or does it use them from the Deadline repository.
Example:
I’m currently working on an eventlistner to communicate with a project management tool via , so I’d like to integrate a library on the Deadline repository or somewhere the eventlistner has access to. Unfortunately, while looking through the documentation, I have not found a proper solution.
Beside that I am wondering if it is possible to use selfwritten modules/classes as well?
thanks
Philipp
We generally have three approaches:
- Code on the Deadline repository - usually it is things that are conceptually closer to the Deadline side, or depend on Deadline libraries. We add paths to
sys.path
after forming them with RepositoryUtils.GetRepositoryPath
or similar.
- Code installed on the machine - Python packages get installed through pip and reside in the Python installation’s
site-packages
directory. This directory also gets added to sys.path
in preparation scripts. This makes development and deployments much more orderly. We also use a local devpi server for distributing packages on all machines.
- Code on another local network location - network drives in Windows. Almost all our Shotgun code and configuration is located there. Also gets appended to
sys.path
. The paths are dynamic (project-dependent) which makes this a bit more complicated.
There are a couple of gotchas.
Deadline uses its own interpreter, so it might break with certain libraries. Especially lower level c-interacting stuff. I believe Deadline libraries are linked into the interpreter, so they are only available within it.
Deadline also has a set of libraries installed on the machine, which might clash with other dependencies or cause incompatibilities. You have to mind load order, and even then it’s not certain.
imo Deadline does not have great support for libraries that are outside its Plugin/Event/Etc. structure. And it is beneficial to be able to share code among multiple such plugins.
By default the local site-packages
is not included, since another interpreter is used.
It still can work, with a bit more effort. Expect some pain, though.