Add update functionality to rez-suite about rez HOT 5 CLOSED

Dynamic Contexts?
After writing the PR and thinking about it more, the less I understand the reasoning behind contexts and why they have a frozen resolve graph stored in them.

• Currently if packages update with bug fixes, I can't automatically get those new packages with manually updating my contexts (or if the PR gets accepted by manually updating the suite).

• Does it not make more sense to store contexts simply as lists of requests and dynamically solve them every time? Then if I'd want to lock a context to a certain version, I could just specify that with the request version syntax.

Example:
I want my studio to use Houdini 19.5. The houdini context file contains the request version: houdini-19.5.

• Currently every time a new subversion comes out, I create a new rez package, release it, then I update my suite to resolve again to the latest houdini version.

• If it was dynamically evaluated I would only have to release a new houdini package and the context would automatically resolve to the latest available package without me having to update the suite/context. And if I want to lock it to a specific version, then do it like any other package manager by just specifying houdini<19.5.340.

Off-Topic
I understand this is getting a little bit off-topic, but I think it's still related enough. I'm curious what the design decisions were behind the current workflow, so I can understand it all better.

from rez.

We never used rez-suites precisely for the reasons you mention. We much prefer store the requests down to the minor versions, resolve that and always get the new patch versions automatically.
You can write yourself a rez-launcher that reads the requests for the project (it can be granular down to the shot or the department if you want) from some source and send that to rez.

from rez.

Thanks Francois!
That makes sense to me, but isn't that exactly what suites were supposed to solve, so that not every studio had to write their own rez-launcher?

And if suites were meant to solve that issue, I think the way you and I are describing the desired behavior would probably make more sense then.

from rez.

That makes sense to me, but isn't that exactly what suites were supposed to solve, so that not every studio had to write their own rez-launcher?

No. Rez tries very hard to not do any kind environment management. A quote from Allan (the author of rez):

Rez very deliberately does not attempt to manage production environments. For example, the system that would define say, which packages to use when running maya in show X, is outside the scope of rez.

And we want to keep it this way.

Another quote from Allan again:

So to answer your question - I try to stress to people that rez is a package manager, not a production environment manager, so yes you are right, Rez is more like the tool/API you would use after your bootstrapping process has happened. There are lots of different ways you could do this. For example in Rez-2, there is something called "suites". A suite can be thought of as like a more general python virtualenv (more general because it can contain any type of package, not just python modules). You can create a resolved environment in Rez, and then store that into a "context file" (.rxt extension). This file can be used later on to resurrect the same environment again. The resolving has already happened so the solver isn't run again - a context file is a 'bake' of a resolve. A 'suite" collects a set of contexts together, places them all into the same directory, and then creates wrapper scripts that expose all the tools available in the various contexts, in a single path. If you have a suite, all you need to do is add its ./bin path to $PATH, and then you can run any of its tools from an unconfigured environment. This is quite a powerful concept and its what we here at Method are going to use in our own production bootstrapping. Basically, in this scenario you would somehow create the suite that you require for each show/shot/etc ahead of time, and then 'source' that suite at bootstrap time by adding it to PATH.

(Taken from https://groups.google.com/g/rez-config/c/swDFcuB2o5c/m/wAci9D8AwEsJ)

The analogy to virtual environments is not necessarily the best though. But this quote shows the intent behind suites.

Note of warning, that thread I just linked contains some old information that might not be representative of the latest rez.

from rez.

Since we have no received any other comments/reply in this issue for a couple of months and I think think the currently suggested feature is something we want to have in rez, I will close this issue.

from rez.