On Oct 2, 2013, at 3:04 PM, Jesse Kretschmer <je...@krets.com> wrote:
> @Nathan; Thank you. I appreciate the energy you have put into these
> responses.
>
> @Everyone, I agree that it would be best to define on the environment before
> launching the application. Unfortunately, that's not my call at the moment.
> I'm working on my argument and this discussion is great fodder.
>
> Excuse the following rant explanation, but I'm can probably learn a thing or
> two by this peer review.
>
> Before I arrived at this company, they had already arrived at a universal
> NUKE_PATH which points to a network drive. The only core pipeline tool was
> the in-app project selector, and script loader.
>
> All other management of the init.py and menu.py was done by whoever was
> motivated. From what it seems, all files were edited in place and would often
> cause studio wide nuke failures due to typos. Additionally. there was no
> version control or formalized development process. All this with 100+ nuke
> artists.
>
> Most of the nuke pipeline was created by the technical artists. My choice to
> execute init.py and menu.py offers familiar way to handle the nuke
> environment. The intent is to scope these rapid developments and possible
> mistakes to a specific projects.
Jesse,
Not sure if this will be helpful or not, but… At our facility, our developer
has set up a set of directories where we (more technically oriented) artists
can put our custom tools. In the menu.py, it has something like this:
try:
import User_Tools
import nukescripts
except:
pass
Our custom bits go in the User_Tools module/menu structure, which is segmented
by user. So, each user's tools will try to be imported via an __init__.py
file -- which does the job of getting the tool module names and building the
menus and submenus for each user's tools. If I goof up something in my own user
section, it will display a message about not loading my tools, but will
continue to load other's tools and will continue to load Nuke. This has worked
well for us. However, we are not trying to change horses in mid-stream, as it
seems you are…
Rich
>
> I hope I don't just sound like I'm whining. I do wish there were more
> developers. There have only yet been a couple artists that have expressed a
> solid understanding of programming. I'm trying to get these folks to use our
> version control system to contribute code. For the remaining hack-and-paste
> contributors, the project based init scripts are at their disposal. The
> project context switching is still going to happen through our in-app project
> switcher.
>
> Should I offer a global shared development folder to provide a consistent
> startup environment, or should I modify the environment once the context is
> known, which only happens in the application?
>
> There are no right answers, but a decision is better than none. I like to
> pretend that I can at least distinguish better from worse.
>
> Thanks for the discussion. I feel like I owe you all a beer for enduring my
> rant.
> Cheers,
> Jesse
> _______________________________________________
> Nuke-python mailing list
> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
Rich Bobo
Senior VFX Compositor
Armstrong-White
http://armstrong-white.com/
Email: richb...@mac.com
Mobile: (248) 840-2665
Web: http://richbobo.com/
"Few will have the greatness to bend history itself, but each one of us can
work to change a small portion of events, and in the total of all those acts
will be written the history of this generation."
- Robert F. Kennedy_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
