Default to using the entire tool lockfile. (Cherry-pick of #18793) #18807
Conversation
The initial implementation of installing tools from regular user lockfiles was designed with the feature of subsetting from a larger lockfile in mind. Therefore, we introduced the `requirements` option, which enumerated the requirements to be installed for the tool, and defaulted to the requirements in the built-in lockfile provided with Pants. However now that users have started experimenting with this feature, it turns out to be quite laborious - in the more common case where you create a custom lockfile that is intended to be used in its entirety, you still have to update `requirements` (e.g., to tweak versions or add extra requirements) even though you already enumerated the requirements as inputs to lockfile generation. This PR changes the semantics of the `requirements` option. It now defaults to an empty list, indicating that the entire lockfile should be used. Only if you truly need to subset do you enumerate `requirements` (which can be versionless, since the lockfile provides the version). This has the side-effect of no longer validating that a custom tool lockfile provides a tool version that Pants believes it can handle. But this nannying has also been found by users to be annoying, and is an example of Pants getting in the way (users were just bypassing this check by updating versions in `requirements`, which seems like unnecessary hoop-jumping). Now if a user-provided tool version doesn't work, e.g., because a CLI arg is no longer available, or other semantics have changed, then the user will get an error, or unwanted behavior, from the tool, and it will be up to them to YOLO that. This change doesn't require deprecation, since the `requirements` option has not been released yet.
|
I'd prefer to hold picking this until we can confirm wether it actually resolves #18625 in which case we could treat it as bugfix. As is it's labeled as a user api change, and I'd rather we maintain a somewhat strict policy of only picking bug fixes. |
|
For this specific change, I suspect the assumption in:
means it is nicer if it is picked: without the cherrypick, the underlying feature will be released (in 2.16) and #18793 will go out in 2.17, and thus require adjustment/deprecation. Per #18806 (comment), sounds like it probably would've been better for me to ask about these on Slack instead of just jumping in. Hopefully we can have a productive discussion here anyway 😄 |
|
Seems I'm the only one awake at the moment. I'm not entirely up to speed on the changes them selves so have merely replied with what we want to pick (bug fixes, in general). These changes may very well be something we want/should be picking. I'll let @benjyw et al weigh in on that. |
|
Yep, as before this should have been cherry-picked by me, or at least tagged. I'm distracted by PyCon... Thanks @huonw ! |
The initial implementation of installing tools from regular user
lockfiles was designed with the feature of subsetting from a
larger lockfile in mind.
Therefore, we introduced the
requirementsoption, whichenumerated the requirements to be installed for the tool,
and defaulted to the requirements in the built-in lockfile
provided with Pants.
However now that users have started experimenting with this
feature, it turns out to be quite laborious - in the more common
case where you create a custom lockfile that is intended to be
used in its entirety, you still have to update
requirements(e.g., to tweak versions or add extra requirements) even though
you already enumerated the requirements as inputs to lockfile
generation.
This PR changes the semantics of the
requirementsoption.It now defaults to an empty list, indicating that the entire lockfile
should be used. Only if you truly need to subset do you enumerate
requirements(which can be versionless, since the lockfile providesthe version).
This has the side-effect of no longer validating that a custom tool
lockfile provides a tool version that Pants believes it can handle.
But this nannying has also been found by users to be annoying, and
is an example of Pants getting in the way (users were just
bypassing this check by updating versions in
requirements, whichseems like unnecessary hoop-jumping).
Now if a user-provided tool version doesn't work, e.g., because a
CLI arg is no longer available, or other semantics have changed,
then the user will get an error, or unwanted behavior, from the tool,
and it will be up to them to YOLO that.
This change doesn't require deprecation, since the
requirementsoption has not been released yet.