On Sun, Jun 28, 2015 at 9:50 PM Marcus Ottosson <[email protected]> wrote:
> ... > > The top-most benefits I’ve found about each is that (1) puts you in a > shell environment identical to the one an application will have once > launched whereas (2) eliminates the risk of conflicting environment > variables, such as not being able to build an environment for both Maya and > Houdini due to both making use of LD_LIBRARY_PATH. Though I can see the > perceived value of (1), I can’t quite figure out a practical use case for > it, whereas conflicts are very real and difficult to work around. Any input > here would be most helpful. > I've seen both (1) and (2), and I would opt for (2). While you can always combine things like LD_LIBRARY_PATH, the entire environment still has to agree on things and you could have compatibility conflicts. Approach (2) should restrict those dependencies to just that given application. (1) would be easier to do, since you just put everything into that env and away you go. (2) I think implies a bit more work to make sure that you not only bootstrap the application you want to launch, but also include anything it might need, like plugins, or dependencies that will be used by tools that are run within that app. > Maybe be could have a plugin that could allow it to make references to > rez packages, and allow you to be into a context that resolves a set of rez > dependencies, and then you end up with full environment and package > management? > > I’ll try and experiment with this next week, spontaneously I considered > having rez trigger on an “enter” script. > > $ be in myproject myasset mytask > Building rez environment.. > > But then the question is, which applications do you build for? > I think you would have to have a registration of packages for a given context. So "myproject myasset mytask" would derive some kind of package list, at least from the project level, and then you just build that environment. > You could pass extras to the be command. > > $ be in myproject myasset mytask --apps maya,nuke,houdini14.5 > Building rez environment.. > > Or maybe you could defer. > > $ be in myproject myasset mytask > $ be apps maya,nuke,houdini14.5 > Building rez environment.. > > It would probably be ideal that users would not have to specify versions of things they will use, since that should be dictated by the project configuration (or any location beneath the project that may have overridden the package definitions). Lets say your studio uses Maya. You may have ProjectA that is deep into production and crunching on Maya2014. Then you have ProjectB just setting up, and they want to test out Maya2016. You don't want to change the Maya version for ProjectA while they are in production. And you also don't want to make people remember to launch Maya2014 on ProjectA and Maya2016 on ProjectB. A user probably just wants to type "maya" and get the right one. Furthermore, maybe on a given show they want to test a new version of software only on a specific sequence. So if you were able to maintain a registry of versions of software for different locations, then "maya" is just the correct Maya, wherever you run it. > In which case maybe rez could be used as-is, without any particular > integration? > > $ be in myproject myasset mytask > $ rez maya,nuke,houdini14.5 > Building rez environment.. > > The latter seems perhaps the most flexible, doesn’t incur any > development/maintenance costs on part of be and also doesn’t eliminate > existing be application environment support nor the use of wrappers. > > Would something like that suffice? > > > -- > 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/CAFRtmOAGir9OAunGD8Vythjw7P_ixDT74CFsAVug%3DW2B4A-vAw%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAGir9OAunGD8Vythjw7P_ixDT74CFsAVug%3DW2B4A-vAw%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/CAPGFgA1n5%3De8nsuHzr8hbxTz-2EWgmKN8--qS57j8o%3Ddwif_vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
