I'd like a way for the rez-context command to accept an input-context and output-context-filename, and perform a particular type of "redaction" / "scramble" on the contents of that context file.
The spec would need to be that "all package names are scrambled to become a random word or small set of words, where each representation of the same package in the context becomes the same new scrambled name". In this manner, studio specific package names would effectively be redacted.
However, I would prefer not to stop there. Since it can be quite obvious which packages might be which real names, owing to the likelihood of certain key packages having very specific/common versioning and request patterns (e.g. it is easy to identify python or USD due to their common and well-known versioning schemes and current versions available in public), certain inferences can be made about which packages are which.
Therefore, I would like the package versions to also be scrambled to different versions, but, in a manner which preserves the relative rez-solver-relative-relationship between the request, any overlapping requests, and the overall union logic of the solve. So a "python-3.10.3" can't become "snafu-6.5.7" without relevant upstream requests also being adjusted to select for their constituent part of that solve. This is tricky since requests will overlap in weird and unpredictable ways.
There might need to be a sidecar produced "mapping" file that allows the user to understand which package names or versions got converted to which, so that they could translate a diagnostic request from "I don't understand why python-3.9.2 conflicted with USD-26.08 in this way in this solve" to "I don't understand why snafu-5.6.3 conflicted with garbley-9.2".
Motivation
For debugging and development purposes, companies being able to share their rez contexts with maintainers can be useful, but they often can't, because doing so might convey confidential information with their contexts. Some studios make rez packages with show-names in or as their names, which might be considered confidential and unshareable. I'd like a way to make these contexts shareable in a diagnostic sense, but not convey internal studio information.
This might interrelate with another feature request I'd like to articulate about being able to provide an entire diagnostic "repository" of package-definitions, but I haven't thought through all the implications of that just yet.
I'd like a way for the rez-context command to accept an input-context and output-context-filename, and perform a particular type of "redaction" / "scramble" on the contents of that context file.
The spec would need to be that "all package names are scrambled to become a random word or small set of words, where each representation of the same package in the context becomes the same new scrambled name". In this manner, studio specific package names would effectively be redacted.
However, I would prefer not to stop there. Since it can be quite obvious which packages might be which real names, owing to the likelihood of certain key packages having very specific/common versioning and request patterns (e.g. it is easy to identify python or USD due to their common and well-known versioning schemes and current versions available in public), certain inferences can be made about which packages are which.
Therefore, I would like the package versions to also be scrambled to different versions, but, in a manner which preserves the relative rez-solver-relative-relationship between the request, any overlapping requests, and the overall union logic of the solve. So a "python-3.10.3" can't become "snafu-6.5.7" without relevant upstream requests also being adjusted to select for their constituent part of that solve. This is tricky since requests will overlap in weird and unpredictable ways.
There might need to be a sidecar produced "mapping" file that allows the user to understand which package names or versions got converted to which, so that they could translate a diagnostic request from "I don't understand why python-3.9.2 conflicted with USD-26.08 in this way in this solve" to "I don't understand why snafu-5.6.3 conflicted with garbley-9.2".
Motivation
For debugging and development purposes, companies being able to share their rez contexts with maintainers can be useful, but they often can't, because doing so might convey confidential information with their contexts. Some studios make rez packages with show-names in or as their names, which might be considered confidential and unshareable. I'd like a way to make these contexts shareable in a diagnostic sense, but not convey internal studio information.
This might interrelate with another feature request I'd like to articulate about being able to provide an entire diagnostic "repository" of package-definitions, but I haven't thought through all the implications of that just yet.