Our solution at my studio more our less matches what Paul described. We have a 1000+ workstations and a custom environment management system. Our plugins are deployed as versioned packages and the environment describes which ones to load up. We would never delete old plugins, because if you went to rerun old shots from an archived show, they would need to run under their original environment again. The problem with people having stale shells and Maya sessions is quite common, but we don't do anything so invasive as forcing reboots. It is up to the individual to watch for pertanent release notes or have a good habit of reloading every so often.
On Tue, 30 Dec 2014 7:40 AM David Moulder <[email protected]> wrote: > Our system is just a python module and has a startup method much like > maya's initialise(). It handles copying plugins and python / mel files > from the repository using robocopy. The repository has configs that are > like manifests files that describe the folder, it' contents, what version > of maya it should run on etc. Depending on this manifest we add unpack > these as python modules, plugins etc on the users local machines. We've > just moved this logic to Perforce and it's was painless, sped up the users > boot time. We adde a tray app and icon in windows to tell the user updates > are available. They run the Perforce update from the tray icon. Then > reboot maya. The perforce stuff is still robocopied to a single local > location. So plugins are not locked. > > > > On Mon, Dec 29, 2014 at 5:01 PM, Marcus Ottosson <[email protected]> > wrote: > >> Also doing this on a daily basis seems pretty inconvenient for a render >> farm, that probably shares the same plugins as production >> >> Ah yes, not sure this relates to render farms. What size of studio are we >> talking about here? If it’s about 20 ppl, all running Windows then things >> are likely a little different then if we’re talking 500 ppl running Linux. >> >> In the case of 500 workstations, I think each machine on a render farm is >> typically capable of running a variety of versions on the fly, via >> environment configuration based on which job is coming in. >> >> For example, if a job is sent out to render a scene with the following >> requirements. >> >> "app": "maya-2013x64", >> "render": "arnold-1.0", >> "plugins": ["somePlugin-10.1.12", "someOtherPlugin-1.0.0"] >> >> Then the machine could set environment variables (i.e. paths to where >> these versions reside) for these to get picked up during the boot cycle of >> Maya prior to initiating a render. >> >> Ultimately, it depends on how flexible you need to be. If you render all >> projects using the same version and software, then life will be a little >> easier. >> >> Maybe it would be the best if pipeline TDs could enforce a global restart >> with a 10min warning period for artists to react!? >> >> This was the case for us (at Framestore), typically after-hours and if >> you worked late you could cancel the restart, which would try again a few >> hours later. >> >> I’ve seen videos of Tools (Unreal Editor) where they do on-the-fly >> replacement of compiled code while the engine is running. >> >> I think the key is to keep your dependencies modular so that you can >> configure your environment “on the fly” - i.e. by configuring the target >> render machine prior to launching. It’s conceptually similar to setting the >> PYTHONPATH, regardless of which tool or OS you use but if you do have a >> look at Rez you’ll get a sense of how complex it can get. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD3KgCXbcDp%3DX%2B98MUtwyGqfk9M4CtxW83Ti1VXWYg31Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD3KgCXbcDp%3DX%2B98MUtwyGqfk9M4CtxW83Ti1VXWYg31Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > *David Moulder* > Technical Animator / Artist > [email protected] > *Professional Profile <http://uk.linkedin.com/pub/david-moulder/1/b12/b5a>* > > Mobile: +44 (0)7814033242 > See who we know in common > <http://www.linkedin.com/e/wwk/5748982/?hs=false&tok=3tztwkse1silw1>Want > a signature like this? > <http://www.linkedin.com/e/sig/5748982/?hs=false&tok=3pwLU9-mBsilw1> > > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CABD4PkTsBXhRqCc1EryaguzPi8FPgSkm2mjTRDC%3DcjvDfQygTg%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CABD4PkTsBXhRqCc1EryaguzPi8FPgSkm2mjTRDC%3DcjvDfQygTg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0aeavYcVbPDLqoP3wuXS8CHVjL8JkQCEFs2pXRMv-ayA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
