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.