Thanks Roy, for getting a conversation started. :) Great stuff, thanks for sharing.
You are very welcome, Eduardo! I wonder if be could be combined/integrated with rez to provide the full suite that is similar to what we have internally? I actually just got together with a studio the other day who is using rez to discuss how be could potentially supersede their in-house tools and we came to a similar conclusion. I got to have a little closer look at what rez actually solved for them and it seems from first glance that a separation can be made clear enough for be and rez to work together. - be does project environment, and a little bit of application environment - rez does application environment, with a little bit of project environment For example, the dependency resolution handled by rez and ecosystem <https://github.com/PeregrineLabs/Ecosystem> isn’t something be will do, in the same sense that building and jumping between directories isn’t something rez does. In this case, be would provide available software, and rez would resolve their dependencies and set up their environment. In regards to application environment, there seems to be two schools of thought. One, which is what rez does, is to (1) build an environment fit for each software into the current process - for example, you might want maya, nuke and houdini. Once built, each application is available to you and you launch the one you intend to work with next. The other method is wrappers, which is what I originally had in mind for be before learning about the former. In this case, an environment is (2) built according to a project, user and task - more or less everything *except* an application. The application environment is then built by the wrapper, which is typically a shell script setting up an environment prior to launching the application. 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. 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? 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.. 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. For more options, visit https://groups.google.com/d/optout.
