Nuke, unlike most other apps installs a new folder structure every sub-version. A lot of times users will submit with one version, say 6.3v4 but our farm might be up to 6.3v5.
I propose the plugin changes from an explicit path to an token based system.
So that you can direct the path to:
C:\program files\nuke$VERSION\ path system.
That way if someone submits a 6.3v5 it can go to C:\program files\nuke6.3v5\
If it doesn’t find 6.3v5 it can just go to the highest version number folder that does exist within that point release (and print a warning in the log).
Actually it would be great to be able to apply a similar, more flexible behavior to any plugin that currently stores a hardcoded list of available versions. A simple solution, similar to what Gavin is saying, is to:
Define a list of version strings
Define an executable command, either absolute or relative, that could include the version tokens
When a job is submitted, require the version to be attached to the job description by the submission process (could be inferred for something like Nuke, but would need to be specified manually in many cases)
A more complex system might allow you to define a regular expression or other ruleset to pull apart each version string into a set of subtokens, which could then be used arbitrarily to assemble an executable path.
I think it’s worth considering the addition of a DeadlinePlugin subclass (called VersionedDeadlinePlugin or something similar), with an implicit awareness of multiple versions of (essentially) the same application. It could pull the available versions from the .dlinit or .param file, and would know how to assemble a token string (defined by the user and stored in the .param file) into an executable path based on the selected version. The base plugin class could also implement a straightforward method of defining behavior switches based on the active runtime version of the application.
For what it’s worth, all of this is based on things we already do, so if we end up switching to Deadline, we will be implementing it whether or not it’s available directly (including, likely, a VersionedDeadlinePlugin class). However, I think it may be something worth keeping in mind, if not for some 6.x release, then down the road.
If we do end up switching, we will either be editing all of the distributed plugins, or rolling our own, to remove all absolute executable paths, and instead setting up versions through a shell environment/package management system. For example, the Nuke plugin will likely have no user-facing executable to define, but will always simply call ‘Nuke’ (or an executable Python script).
I would add that typically we lock down versions of software per show/project.
So any token based system would need to RegEx such information out and make a decision on what to do.
Sounds like Shotgun could help here…
Well conceivably, if you’re freezing versions, you have the associations defined somewhere in your pipeline (in a production database, in your shell environment, etc). So it would be pretty simple to add a submission check to make sure the version the user is submitting is appropriate for the project they’re working on, and error if necessary.
However, at that point, it’s really too late. If you aren’t enforcing versions and raising errors using callbacks or environment variable checks before the artist actually starts working, the damage is already done.
Even the smallest version difference between software on an artist’s workstation and a render node can potentially result in the output being noticeably different. We’ve all seen flickering renders caused by subtlties like this.
I expect each studio would want their own logic for version selection, and, as a result, probably will need to author their own python module to interface with the studio pipeline. It should be straight forward, in most cases, to modify the plugins to call the studio module rather than (or in addition to) reading from the dlinit file. The downside, of couse, is that changes to shipping Deadline plugins would need to be re-added whenever the Deadline plugins are updated.
I would be interested in the use cases surrounding this and also to hear of what challenges came up for anyone that implemented hooks into their stuido pipeline.