.building<VERSION> lock file does not treat multiple variants atomically

The filesystem keeps the version if a .building file for the version is present, but a valid package.py is present in this version.

This is probably to respect canceled builds which did not clean up the .building file. Or maybe it is also assumed that a released variant can technically be available in the resolve regardless of other variants still being build.

The package.py is being written after each variant (adding its variant each time, which by the way is another source of problems that I will reveal soon: Parallel variant build might break ...)

That may be intended but for us, with non-mutually exclusive variants it cause issues as with the default orderer a latest version is preferred even though the variant may not perfectly match (yes, python variants again causing trouble).

I am not sure what the best approach is, if this is only us I would write my own filesystem plugin and replace the default one.

Bottom line is: We would love rez-release with multiple variants to be atomic in the eyes on the .building lock file.

Start by tracing the default filesystem plugin's handling of the .building lock file and package.py, then examine how rez-release writes multiple variants and how the default orderer resolves them. Done means determining and documenting an approach that makes all variants of a release appear atomically, with behavior for canceled builds and partially written package.py files.

Written by the indexing model from the issue text.