I have been following the tool lockfile removal - ...
# development
I have been following the tool lockfile removal - exciting stuff. I have worked on adjusting the behavior of
, so simplifying all the code is a boon. I did not, however, have the full context for the extent of the change. So, trying to understand the plan (I’m looking forward to all of this!):
The difference is when you want a custom one, you point it to some named resolve, rather than this special mechanism just for tools.
The drawback for the user is that to create a custom tool lockfile they now also need a requirements.txt (or to add the tool to an existing one) where previously they just made a change in pants.toml. But it was always weird to define requirements in pants.toml instead of in targets, I think.
So, does this mean that, taking
for example (with appropriate deprecation cycles): • Remove options
• Replace those options with
which references a resolve from
• Users can now use
as a resolve name, as it is no longer reserved for the
tool lockfile • Some kind of error checking that ensures
is present in the chosen resolve Is that the planned UX?