Make lock update sensitive to artifacts. #1887
Conversation
Previously lock updates were sensistive to changes in pins but not to changes in the set of artifacts when pins remained unchanged.
Previously there was ambiguity in the key used to store built wheels when the local OS (platform tag) could take on different values as is the case in macOS Big Sur where 10.16 and 11.0 are synonyms.
|
The second commit is needed for green CI but is off for seperate review in #1886. |
|
This shortcoming in functionality was reported by @zmanji in Slack - no associated issue. |
| class Value(Enum.Value): | ||
| pass | ||
|
|
||
| IGNORE = Value("ignore") |
There was a problem hiding this comment.
Does ignoring in this case amount to adjusting the lockfile to use a new fingerprint? Or will it keep the old fingerprint? Should this have a different name that clarifies that?
There was a problem hiding this comment.
When you ignore the mismatch, the new fingerprint is used. I expanded the corresponding option help to document what each value does.
| def _calculate_requirement_configuration( | ||
| self, | ||
| locked_resolve, # type: LockedResolve | ||
| pin_all=False, # type: bool |
There was a problem hiding this comment.
Given that this is pin_all (implying that a different scope of pinning might be necessary/useful), should the --pin flag maybe start as either an enum, or perhaps a list option with an initial special-case value of e.g. :all:?
There was a problem hiding this comment.
I don't think so. The two existing modes of lock update are:
- no args: Update the lock given its original input root requirements (these are stored in a lockfile)
-p one -p "two<2" -p three==1.0...: Update the lock pinning everything else and just updating (or adding) these projects if possible.
So this just offers the only missing mode as far as I can tell (besides allowing for project removal) - update the lock keeping everything --pinned.
Functionally, the 1st mode updates the lock to the latest available needed to satisfy the root requirements. The second mode is a targeted update - I need a specific security fix or bug fix. This third mode allows just switching indexes / repos or picking up newly published artifacts. You can do this with the 1st two modes, but they also force you to change some pin. In order to not change a pin, you'd have to use mode 2 and pick one project pin from the existing lock by inspecting it and then use that on the CLI to effect the new --pin (all) behavior; so --pin is just a short cut for a human and a firewall for a machine - which should not be trying to parse an opaque-still lock file format it has no business knowing.
For all other updates you simply must use create instead - at that point it becomes a new lock.
Previously lock updates were sensitive to changes in pins but not to
changes in the set of artifacts when pins remained unchanged.