Building file should be more atomic

[boredstiff]

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.

[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.

[boredstiff]

That's a good point @instinct-vfx - that seems to be the consensus for user expectation from the thread.

[pmolodo]

We would prefer this behavior, as it's nice to have an easy way to temporarily disable/hide a package.

[nerdvegas]

It looks like we've converged on the same solution, almost. I think we still need to have .building files, as well as .ignore. The reason is that a failed release could easily result in .building files getting left behind; these actually get deleted at a later point in time (see filesystem.py: _delete_stale_build_tagfiles). However we would never want to do this for .ignore files, the assumption being that these have been explicitly added by somebody. A

…

On Fri, Jul 14, 2017 at 8:49 AM, Paul Molodowitch ***@***.***> wrote: We would prefer this behavior, as it's nice to have an easy way to temporarily disable/hide a package. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#445 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjqShiEvtPiEN1miCg_MxnobXSgDiHvks5sNp7ggaJpZM4OXHgt> .

[instinct-vfx]

I completely agree on making that distinction.

[skral]

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

[nerdvegas]

Just adding to this old thread as everybody (myself included) missed an important point.

.building files cannot be used to ignore the package completely, because they can exist after a package has been released, while a new variant is being installed into the package.

A recent update now means that package.py updates are atomic, and so I do wonder if the .building file needs to be created for the non-first variant anymore.