Add [python].enable_resolves and [python].experimental_default_resolve
#13967
Conversation
…olve` # Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust] # Building wheels and fs_util will be skipped. Delete if not intended. [ci skip-build-wheels]
| ), | ||
| ) | ||
| register( | ||
| "--enable-resolves", |
There was a problem hiding this comment.
Would it be ambiguous to call this "require-lockfile" or something? It's not quite clear what "enabling resolves" would mean, and most users will only be enabling lockfiles, rather than enabling multiple resolves.
There was a problem hiding this comment.
I think it'd be a little confusing because we've in the past called "constraints" a "lockfile", so it's an overloaded term. And we have --experimental-lockfile which we know a few users are using.
I went with --enable-resolves because the overall new feature can be called "resolves" to differentiate from the status quo. Even if you only have a single resolve, you still have fields like compatible_resolves, resolve, and --default-resolve. "resolve" is the main way we refer to this feature.
Closes #12742.
Similar to #13925, this adds a default of
{"python-default": "3rdparty/python/default_lock.txt"}. It also lets the user set the default resolve via--experimental-default-resolve.We don't add
--default-compatible-resolves, as decided in #13902.Default file name
The resolve must be unambiguous with JVM, hence using
python-defaultinstead ofdefault.Everyone agreed in Slack that we should use
pythoninstead ofpy, e.g.3rdparty/pythonover3rdparty/py. The clarity is worth it.It's unclear to me if we want the file to be called
default_lock.txt. In JVM, it's calleddefault.lock. We could do that here too? I only went with.txtto make it a bit more clear to users that they can use these lockfiles just like a normalrequirements.txt- Python has a strong convention for this.Deprecation plan:
--enable-resolvesWe want to require using resolves in the future, as we believe it is important for users to have secure and reproducible builds. But we can't switch it on immediately.
At the same time, to make the feature useful, it's really useful for us to be able to set defaults.
To bridge the gap,
--enable-resolvesfeature gates everything. When set, we can act how we will in the future, e.g. assuming that a default resolve must always be set. When unset, we use the status quo. In Pants 2.10, we will deprecate not setting this option so that we can make the default in Pants 2.11 be to use resolves.[ci skip-rust]
[ci skip-build-wheels]