python_requirement uses resolve: str field, not compatible_resolves: list[str]
#14420
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ves: list[str]` [ci skip-rust] [ci skip-build-wheels]
stuhood
approved these changes
Feb 9, 2022
Comment on lines
127
to
+133
| "For now, Pants only has first-class support for disjoint resolves, meaning that " | ||
| "you cannot ergonomically set a `python_source` target, for example, to work " | ||
| "with multiple resolves. Practically, this means that you cannot yet reuse common " | ||
| "code, such as util files, across projects using different resolves. Support for " | ||
| "overlapping resolves is coming soon.\n\n" | ||
| f"If you only need a single resolve, run `{bin_name()} generate-lockfiles` to generate " | ||
| "the lockfile.\n\n" | ||
| "you cannot ergonomically set a `python_requirement` or `python_source` target, " | ||
| "for example, to work with multiple resolves. Practically, this means that you " | ||
| "cannot yet ergonomically reuse common code, such as util files, across projects " | ||
| "using different resolves. Support for overlapping resolves is coming soon.\n\n" | ||
| f"If you only need a single resolve, run `{bin_name()} generate-lockfiles` to " | ||
| "generate the lockfile.\n\n" |
There was a problem hiding this comment.
This statement is still true, but for a different reason now, maybe? Basically, the same sources could have multiple resolves if you 1) declare two targets (maybe with a macro), 2) (in 2.11) use parametrize.
It might be worth calling out 1 as an option, and saying that 2 is coming...?
There was a problem hiding this comment.
The issue is dep inference won't work with python_source, so I figured we shouldn't advertise it. But, if I can knock out #14293 in the next week we could cherry-pick it, then multiple targets is totally viable. Wdyt?
There was a problem hiding this comment.
I supposed that if it would still mean writing your own macros, it's probably ok to wait.
Eric-Arellano
added a commit
to Eric-Arellano/pants
that referenced
this pull request
Feb 10, 2022
…ves: list[str]` (pantsbuild#14420) Generally, we've realized that targets like `python_source` should use `resolve: str`: pantsbuild#14299. This solves several problems, particularly how to choose the resolve when operating directly on `python_source` targets e.g. with MyPy. We wanted to keep `compatible_resovles` for `python_requirement` out of convenience, that it's nice for callers to be able to depend on `//:reqs#numpy` rather than `//:reqs#numpy@resolve=a`. The argument was that `python_requirement` is the "leaf" - it's not directly operated on. That was a bad assumption. `python_requirement` is directly operated on with `export` and `repl`, e.g. `./pants repl 3rdparty/python::`. We were defaulting in that case to `[python].default_resolve` -- but that doesn't make sense! If you're running `./pants repl pants-plugins/3rdparty::`, why would Pants try to use `python-default`? We don't want to get into the business of trying to disambiguate which resolve you want, either, as that's very magical and confusing. Beyond `repl` and `export`, @stuhood has wisely pointed out that this change is important for clarity. Even though `//:reqs#numpy` would have the same raw requirement string, the actual pinned version might change depending on the resolve! For example, `numpy>=2.0,<3` might result in `==2.3.1` in resolve A, but `==2.7.4` in resolve B. _They are not the same thing_. [ci skip-rust] [ci skip-build-wheels]
Eric-Arellano
added a commit
that referenced
this pull request
Feb 10, 2022
…ves: list[str]` (Cherry-pick of #14420) (#14435) Generally, we've realized that targets like `python_source` should use `resolve: str`: #14299. This solves several problems, particularly how to choose the resolve when operating directly on `python_source` targets e.g. with MyPy. We wanted to keep `compatible_resovles` for `python_requirement` out of convenience, that it's nice for callers to be able to depend on `//:reqs#numpy` rather than `//:reqs#numpy@resolve=a`. The argument was that `python_requirement` is the "leaf" - it's not directly operated on. That was a bad assumption. `python_requirement` is directly operated on with `export` and `repl`, e.g. `./pants repl 3rdparty/python::`. We were defaulting in that case to `[python].default_resolve` -- but that doesn't make sense! If you're running `./pants repl pants-plugins/3rdparty::`, why would Pants try to use `python-default`? We don't want to get into the business of trying to disambiguate which resolve you want, either, as that's very magical and confusing. Beyond `repl` and `export`, @stuhood has wisely pointed out that this change is important for clarity. Even though `//:reqs#numpy` would have the same raw requirement string, the actual pinned version might change depending on the resolve! For example, `numpy>=2.0,<3` might result in `==2.3.1` in resolve A, but `==2.7.4` in resolve B. _They are not the same thing_. [ci skip-rust] [ci skip-build-wheels]
stuhood
added a commit
that referenced
this pull request
Feb 11, 2022
As designed in #13882 (and elaborated on in #14420 in the context of Python), the `parametrize` builtin means that targets which want to support multiple resolves (or Scala versions) should use `resolve=parametrize(..)`, so that a different target is created per resolve. This change replaces the `compatible_resolves` field with `resolve` for the JVM. And in order to allow the `resolve` field to be `parametrize`d, it also moves it from the `core_fields` of JVM target generators (which cannot be `parametrize`d) to the `moved_fields`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Generally, we've realized that targets like
python_sourceshould useresolve: str: #14299. This solves several problems, particularly how to choose the resolve when operating directly onpython_sourcetargets e.g. with MyPy.We wanted to keep
compatible_resovlesforpython_requirementout of convenience, that it's nice for callers to be able to depend on//:reqs#numpyrather than//:reqs#numpy@resolve=a. The argument was thatpython_requirementis the "leaf" - it's not directly operated on.That was a bad assumption.
python_requirementis directly operated on withexportandrepl, e.g../pants repl 3rdparty/python::. We were defaulting in that case to[python].default_resolve-- but that doesn't make sense! If you're running./pants repl pants-plugins/3rdparty::, why would Pants try to usepython-default? We don't want to get into the business of trying to disambiguate which resolve you want, either, as that's very magical and confusing.Beyond
replandexport, @stuhood has wisely pointed out that this change is important for clarity. Even though//:reqs#numpywould have the same raw requirement string, the actual pinned version might change depending on the resolve! For example,numpy>=2.0,<3might result in==2.3.1in resolve A, but==2.7.4in resolve B. They are not the same thing.[ci skip-rust]
[ci skip-build-wheels]