Avoid having to nuke or batch-update your entire repository on changes to your implicit request, such as platform_map = {"os": { r"windows-10(.*)": r"windows-10"}}.
Motivation
There's nothing worse than updating your OS only to find that none of your packages containing the version of your OS as a variant aren't working anymore. This is a silent but deadly design flaw of Rez, forcing the new user into making a decision they cannot possibly hope to understand without significant experience with Variants and its pitfalls. Once a repository has been authored, it is designed to be immutable, thus it cannot be fixed once it becomes a problem, but must be fixed beforehand.
Issues
Unpredictable. Which makes it error prone and unreliable. See probably?
Makes package.py mutable. Each variant is not only another folder, but also an edit to the package.py which means it cannot be parallelised or atomically transferred between repositories.
Implementation
This can be addressed from one of two points.
Fix the user
Fix Rez
Fixing the user involves writing documentation and making it apparent, especially to the beginner, what needs to happen prior to designing your package repository. Given the complex nature of the issue itself (e.g. only occurring during an update to the OS, very hard to reproduce and debug, and rarely an issue), the resulting complexity of the necessary documentation would incur a cost to user experience and ultimately adoption.
Fixing Rez is another alternative, although it's not clear exactly how. Consider the issue Variants try to solve, and provide an alternative. Something capable of living side-by-side with Variants, but doesn't suffer from the aforementioned issue.
Representation: Facilitate use of one version across multiple platforms, or more generally, multiple "targets" such as versions of a host application like Maya.
Requirements
Provide two or more Representations of the same version, under a unique key
Representations are optional, with one implicit "default" if none exists
Different versions may have different amounts of Representations, e.g. v001/[png, jpg] and v002/[png, jpg, abc]
Representations may be added to an existing version with existing Representations
Goal
Avoid having to nuke or batch-update your entire repository on changes to your implicit request, such as
platform_map = {"os": { r"windows-10(.*)": r"windows-10"}}.Motivation
There's nothing worse than updating your OS only to find that none of your packages containing the version of your OS as a variant aren't working anymore. This is a silent but deadly design flaw of Rez, forcing the new user into making a decision they cannot possibly hope to understand without significant experience with Variants and its pitfalls. Once a repository has been authored, it is designed to be immutable, thus it cannot be fixed once it becomes a problem, but must be fixed beforehand.
Issues
package.pymutable. Each variant is not only another folder, but also an edit to thepackage.pywhich means it cannot be parallelised or atomically transferred between repositories.Implementation
This can be addressed from one of two points.
Fixing the user involves writing documentation and making it apparent, especially to the beginner, what needs to happen prior to designing your package repository. Given the complex nature of the issue itself (e.g. only occurring during an update to the OS, very hard to reproduce and debug, and rarely an issue), the resulting complexity of the necessary documentation would incur a cost to user experience and ultimately adoption.
Fixing Rez is another alternative, although it's not clear exactly how. Consider the issue Variants try to solve, and provide an alternative. Something capable of living side-by-side with Variants, but doesn't suffer from the aforementioned issue.
Requirements
v001/[png, jpg]andv002/[png, jpg, abc]