-
-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[internal] Add [jvm].default_compatible_resolves
#13902
[internal] Add [jvm].default_compatible_resolves
#13902
Conversation
[ci skip-rust] [ci skip-build-wheels]
# Rust tests and lints will be skipped. Delete if not intended. [ci skip-rust]
I think that the general trend is going to be toward all target types having the So: if we think that in the meantime it is easiest to just have the single entry default option, and then only add support for multiple default resolves if users request it, that seems fine to me. Alternatively, if we think that we can replace the single-entry option immediately (by having targets with the |
Okay, that's fine with me. Let's just have |
…olve` (#13967) 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-default` instead of `default`. Everyone agreed in Slack that we should use `python` instead of `py`, e.g. `3rdparty/python` over `3rdparty/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 called `default.lock`. We could do that here too? I only went with `.txt` to make it a bit more clear to users that they can use these lockfiles just like a normal `requirements.txt` - Python has a strong convention for this. ## Deprecation plan: `--enable-resolves` We 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-resolves` feature 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]
See #12742.
The idea with
default_compatible_resolvse
is to let you set the default to >1, whereasdefault_resolve
would force you to only being able to default to one resolve.While not extremely common, we do suspect there will be some repositories where the majority of your
jvm_artifact
andjava_source
targets work with 2+ resolves, and it's only a few targets that diverge.This should probably be replaced by #13767 eventually.
[ci skip-rust]
[ci skip-build-wheels]