Lockfiles: figure out how to model the default resolve for multiple user resolves #12742
Comments
|
Interesting! #12784 is looking like Java will use the same "named resolves" mechanism as Python. It would be great for This means that the universe of resolve names would be shared across languages. So, we could not rely on using a resolve name like cc @tdyas |
|
#13374 is the relevant ticket for the JVM side of this. |
Or, we can have the defaults be |
Or just |
Part of #12742. We set a default because it's important to the Pants project that onboarding is as effortless as possible, e.g. via sensible defaults. An additional benefit is that we can now be confident a resolve is set up, as it is impossible to override an option to be `None` (#11719). We decided that we want to require lockfiles when using Pants, so this is seen as a benefit. -- This uses the resolve name `jvm-default` because the namespace will be shared with Python, e.g. `py-default`. It uses the lockfile path `3rdparty/jvm/default.lock`. We use the file extension `.lock` instead of `.json` to better express the semantics, including that you should not hand-edit the file. Using the `3rdparty/jvm` folder is a sensible default for monorepos, and people can override it to where they want. [ci skip-rust] [ci skip-build-wheels]
…build#13925) Part of pantsbuild#12742. We set a default because it's important to the Pants project that onboarding is as effortless as possible, e.g. via sensible defaults. An additional benefit is that we can now be confident a resolve is set up, as it is impossible to override an option to be `None` (pantsbuild#11719). We decided that we want to require lockfiles when using Pants, so this is seen as a benefit. -- This uses the resolve name `jvm-default` because the namespace will be shared with Python, e.g. `py-default`. It uses the lockfile path `3rdparty/jvm/default.lock`. We use the file extension `.lock` instead of `.json` to better express the semantics, including that you should not hand-edit the file. Using the `3rdparty/jvm` folder is a sensible default for monorepos, and people can override it to where they want. [ci skip-rust] [ci skip-build-wheels]
…ypick of #13925) (#13930) Part of #12742. We set a default because it's important to the Pants project that onboarding is as effortless as possible, e.g. via sensible defaults. An additional benefit is that we can now be confident a resolve is set up, as it is impossible to override an option to be `None` (#11719). We decided that we want to require lockfiles when using Pants, so this is seen as a benefit. -- This uses the resolve name `jvm-default` because the namespace will be shared with Python, e.g. `py-default`. It uses the lockfile path `3rdparty/jvm/default.lock`. We use the file extension `.lock` instead of `.json` to better express the semantics, including that you should not hand-edit the file. Using the `3rdparty/jvm` folder is a sensible default for monorepos, and people can override it to where they want. [ci skip-rust] [ci skip-build-wheels]
…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]
Two possible approaches:
default, and hardcoderesolvefield's default todefault.In both cases, if the default is not set, then every target will be forced to be explicit.
--
Whatever we do should likely be emulated by "named interpreter constraints".#12652
--
We also need to consider how to model defaults for
compatible_resolveswithpython_librarytargets: #12714. We should almost certainly let the user choose a default that makes sense for them, rather than forcing them into['default']- you may want your default to be >1 element.That suggests we should let the user decide the default for both the
resolvefield andcompatible_resolvesfield.--
In addition to
compatible_resolvessuggesting the second option is better, I also think there's value in letting the user choose a name that makes sense to their org.This is probably much more applicable to named interpreter constraints, but I think option 2 gives better modeling when an org wants to change their default to a new value. Rather than having to retcon
default, they can simply point to the resolve they want. This is more clear with interpreter constraints: if you start with--default=py2, then you can update it to--default=py3. That's better than changingdefaultto have a different value.The text was updated successfully, but these errors were encountered: