[internal] Replace apply_constraints with an explicit list of constraints.
#14064
Conversation
[ci skip-rust] [ci skip-build-wheels]
stuhood
force-pushed
the
stuhood/pass-explicit-constraints-in-pex-requirements
branch
from
9ef02b2
to
6eb21a2
Compare
| @@ -219,7 +219,8 @@ async def pylint_first_party_plugins(pylint: Pylint) -> PylintFirstPartyPlugins: | |||
|
|
|||
| return PylintFirstPartyPlugins( | |||
| requirement_strings=PexRequirements.create_from_requirement_fields( | |||
| requirements_fields | |||
| requirements_fields, | |||
| constraints_strings=(), | |||
There was a problem hiding this comment.
followup to #14058 (comment). Okay sounds good to use constraints on first-party plugins for MyPy, I was misreading the code thinking it was for generating the tool lockfile.
We should also update these Pylint plugins to use it too.
There was a problem hiding this comment.
@Eric-Arellano : You were right: see my comment there. PexRequirements.create_from_requirement_fields is only actually being used to gather the requirement strings, so the constraints are not consumed. I've added a top commit here fixing mypy.
There was a problem hiding this comment.
Got it, thanks! So should it still be an explicit arg for constraints_string?
There was a problem hiding this comment.
I think so... in this case, it calls out that we're (ab)using PexRequirements to gather the requirements rather than to (directly) create a PEX. In any other position you'd want to consider whether to apply the constraints.
Once lockfiles roll out, I think that our current plan will be to remove the constraints...? But they certainly won't be a global singleton anymore.
There was a problem hiding this comment.
Once lockfiles roll out, I think that our current plan will be to remove the constraints...? But they certainly won't be a global singleton anymore.
Yeah, at least for now.
# 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]
stuhood
deleted the
stuhood/pass-explicit-constraints-in-pex-requirements
branch
…ugin resolution (#14058) As discussed in #14053, currently if a plugin uses a range requirement (even if it matches the requirement used by Pants itself), a different version might be chosen than what is already installed in the virtualenv for Pants, triggering a conflict when we try to add it to the working set (i.e. `sys.path`). This change uses the current working set to constrain the plugin resolve, so that plugins with range requirements will choose matching versions from those ranges (if possible). To do that, it consumes #14064 to specify the working set as constraints in the `PluginResolver`. Fixes #14053. [ci skip-rust]
Some callers (#14058) of
PexRequirementswill soon need to be able to specify explicit constraints for building a PEX which are not the global constraints. Additionally, consuming theconstraintsdirectly as a file (rather than parsing and re-materializing the file) forces whitespace/comment edits to the constraints file to invalidate all resolves (reported here).To fix this, replace
apply_constraints: bool(for the global constraints) with an explicit list of constraints.[ci skip-rust]
[ci skip-build-wheels]