First off, I know it may seem like I'm giving you an unnecessarily hard time about this instead of just answering your questions, but believe me, this is all coming from experience. This feature is meant to enable the technical artist to self-serve without direct support from the pipeline department. This allows them to offer custom python code and menu options to the other artists on the project. OK, that's understandable, if more than a little inadvisable, but why isn't it possible to just have a release directory for project-specific scripts that technical artists can drop things into? At the end of the day, someone is going to be editing either a menu.py or whatever code the menu.py calls in order to define menu items for scripts, unless you come up with some kind of a convention for defining entry points within modules for automatic binding (and if you do that, good luck getting technical artists to conform to them). So either you are going to be responsible for making sure the initialization code is working properly, or you're going to be turning them loose to potentially break the Nuke environment for every artist who tries to work on that show, at which point you will *still* be responsible for making sure the code is working. I'd like to contain these customizations to primarily gizmos, but there have been many requests to support knob defaults and default formats which is easier handled through a menu.py. There isn't really anything "easier" about it... you can set knob defaults, create formats, and modify the plugin path whenever you want to. Setting up something to crawl the plugin path and add menu items for gizmos is a very useful feature, and one that can be implemented on its own.
My primary goal is to sandbox these changes to a specific project. Core pipeline tools can only be altered by the pipeline department. Any project specific code will only affect those artists in the project context. We have been a little loose with edits up until my recent environment changes. Occasionally a well-meaning artist would apply a global change that would stop nuke from loading. The easy solution here is a layered set of release trees. Set your environment up so the core stuff is always on the plugin path, and then use a callback or some other mechanism to add the project-specific directory appropriately. Also, if you are expecting artists to be contributing code frequently, you should probably designate one or more people to vet their code for bugs and performance issues. I can understand the desire to try and make things seamless for all parties, but at some point you have to stop and ask yourself if it's worth committing more development time and energy to *possibly* gain an extra 1-2% of "spit-and-polish." What you *really* want to avoid is building an elegant system that works great as long as the very specific criteria X, Y, and Z are satisfied but is otherwise very fragile, because you *will* end up having to support the people who are now supposed to be "self-sufficient". To quote another pipeline developer who has seen more than his fair share of scope creep: "There's only so much idiot-proofing you can do before you have to remove the idiot." -Nathan
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
