Building file should be more atomic

Hi,

Description

.buildingX.X.X file should be more atomic in determining a package’s viability for resolution. We feel that the existence of this file should prevent Rez from resolving a package, even if the package.py exists. The reason for this is that if Rez didn’t get to the step where it removes this file, then something failed - and if something failed, we probably don’t want that package to go into production.

Steps to Reproduce

1. Build a package.
2. Leave the package.py file in place.
3. Create an empty .buildingX.X.X file in the package family folder with the X.X.X representing the version.
4. Resolve an environment with this package and version. The resolution points to the built package.

Desired Result

If the .buildingX.X.X file is found, no additional steps should be done to attempt to resolve the package.

Additional

We’re thinking about patching this in our local fork, and if you decide that you agree with this change, I’d be happy to push the changes upstream, but I’m sure we’ll need more discussion about that.

So with this recent discussion happening on the Rez Google Group, we have begun re-evaluating our package syncing solution between our facilities, as we believed the existence of the file would indicate what was described above. Now we are looking at either going with a solution similar to Alexandra’s where our sync agent copies the package.py as a separate job after the package has been synced, or we’re looking at patching our local fork.

[skral]

Added the functionality of an .ignore file and opened a PR #453

[instinct-vfx]

After thinking about it a little i was wondering if it also may make sense to go for a more generic name for the file like .ignoreX.X.X as it seems that one of the main use cases besides releasing is syncing rather than building.