Following up on Pipeline Specification for Versioning, this specification relates to a command-line utility for running software under a given context.
- run "maya" under --project hulk --shot 5
- run "unity" under --project doom --level 5
Where the particulars of the specified executable is inferred via context rather than explicitly stated.
- "maya"
- "maya-2015x64".
Context governs which particular version of Maya to run.
Many of you are bound to have worked with, or possibly developed similar tools now or in the past; your feedback would be awesome.
Are you referring to having access to contextual metadata based on your terminal’s location in a directory tree? I work with a system like this and find it can be the answer to a lot of pipeline issues.
Your specific point is actually something that has come up a few times now; whether the contextual metadata should be based on your current working directory, or if the command itself should alter the environment implicitly.
For example
Me being here
$ /projects/hulk/shots/1000
Gives me access to metadata such as
$ dash $SHOT and
1000
$ dash $PROJECT
hulk
The alternative is to have the command imprint this data upon being called.
$ dash hulk/1000
Environment is being modified
$ (set SHOT 1000)
$ (set PROJECT 1000)
In which case the same metadata is imprinted into your environment and could be accessible from outside of dash
$ echo $SHOT
$ echo $PROJECT
Each come with their own pros and cons, not sure which one would fit an artist’s workflow better.
Added a section to the bottom about the two alternatives as well as some other considerations, let me know what you think. http://rfc.abstractfactory.io/spec/57/
I’d say add the required context when calling. What if i want to run a specific context without being in a project. I’d say, defined dependencies, have a system that resolves them and lets me create environments as i want to based on applications/libs/versions. On top of that you may have a resolver that derives the needed info from the folder, your production tracking database or whatever you want to.
I only know of one more implementation of a similar system:
Do you know of any more?
I’m attempting to stay clear from dependency resolution with dash, and rely more on the bootstrapped command to resolve these. I’m picturing dash to be only a little more than a fancy cd command; resolving dependencies however is a massive undertaking, possibly better handled separately.
You’ll want to provide access to values via an executable and an implementation in Python hopefully. The idea is not to bloat env so generating values in a template contextual file at the top of your tree will give you the ability to access them and mutate those values depending on your location. The command would provide the value of a key in an ordered dict or provide information about the metadata, some kind of introspection. You’ll need an automated way of diseminating the template and version control system in place for making live edits. I think several big studios do this sort of thing.
This is excellent Thorsten, I’ve only briefly seen this software mentioned in the book Production Pipeline Fundamentals and thought it sounded interesting.
I dug a bit deeper, went through their manual and source code. It would seem that Rez is a Package Management System whereas the specification above is an Environment Management System; he defines each here: Home · AcademySoftwareFoundation/rez Wiki · GitHub
I’m looking into the possibility of building dash to provide an interface for Rez towards artists, it seems to handle the dependency resolution that you speak of. Quite thoroughly too, I might add.
