Live Suite

[davidlatwe]

Had a quick chat in Rez slack channel, and got some feedback about how suite is being usded or not being used.

Allan pointed out that suite wasn't easy to maintain in practice, here I quote:

Allan Johns 1 day ago

the general idea with suites was that it would give us stability, since everything is baked, and we have full control over what packages are in any given runtime

in practice this is bollocks 🙂 It becomes someone's job to push through suites, and they don't have enouhg context (in the general sense, not rez context) to make sense of 100's of package updates

we then switched to a "live resolve" system. In this one, the rez-env is resolved at tool launch time

we have different types of locks that give us control over when new package versions becoming visible

I need to talk about it in greater depth sometime because the locking mechanism is really nice. It uses a kind of package orderer called TimestampPackageOrder. This is a way to do a resolve that prefers packages released before a given time T, but will use packages released after T if necessary

what that means is you get the same results as using a standard timestamp, but if your request contains a newer package that did not exist before T, it will still work. Rez will choose the minimal set of packages after T that it needs to, in order to match your request

so if a show really needs that latest bugfix, but doesn't want to change anything else, then they can do that

many package managers have the analogy to this - where you can say "update packages in this (virtualenv or equivalent), but minimise pacage updates". This is like the rez analogy of thta behaviour

you wouldn't author the locks in rez-config because we want them to be different depending on the show/shot etc. You can set different locks on different shows

minimise meaning, if I want a runtime with newer version of foo, don't also give me a newer version of bah if I don't need it

TL;DR

Better resolve context in live, and lock packages when needed with TimestampPackageOrder, a.k.a. soft_timestamp.

Implementation

1. Use our suite.Suite subclass SweetSuite to save out bin tool which instead of loading baked .rxt to create tool context, re-resolve the context's request before forwarding tool command.

2. And save the lock in suite.yaml, then read from there before resolving context.

[davidlatwe]

2. And save the lock in suite.yaml, then read from there before resolving context.

Regarding implementation 2), the lock should be per tool, not per context.

[davidlatwe]

Just found that Allan had replied to the "live suite" :

I get what you mean. It's possible but I'm not sure how useful that would really be. If you want this kind of thing, then you almost certainly want to be changing package requirements over time too, which means generating new suites anyway. It's probably better to keep suites as they are - a collection of static (ie baked) runtimes. I think adding the potential for some dynamic behaviour would confuse things somewhat

what would be very useful is an OS implementation of what we do at Method. We have a kind of config hierarchy that defines runtimes, and tools are launched into their resolved env on the fly. There's a locking system as well. So on a per show/shot/etc basis, you can change package requests, lock times and so on