<@UB2J9BQA0>: it seems like the two halves of `bui...
# development
@hundreds-father-404: it seems like the two halves of
should be split… regenerating our own lockfile is independent of tool lockfiles
for example: https://github.com/pantsbuild/pants/pull/12715 is trying to update
as a user requirement, but ends up updating tool lockfiles as a sideeffect
i don’t think that this will be a broader issue with having a merged
for this (i’m not expecting too many tool lockfiles? although maybe that’s naive), but it’s interesting.
Good point
although perhaps the help will … help
most of the time the actual command we should suggest will be e.g.
./pants generate-lockfiles --resolve=pytest
Yeah we can drop a custom script for our own internal lockfiles. Only value currently is that the user-lockfile command is tricky, which will be solved with multiple user lockfiles Then we have generate_default_tool_lockfiles.sh with all of its overriding of options
most of the time the actual command we should suggest will be...
This is all just tail-chasing though - right? Once locks are generated autoatically, there will only be specific calls to
./pants update-lockfiles
which will be rare and intentional and likely lead to picking just a few instead of all.
correct. but that’s potentially multiple releases from now (via https://github.com/pantsbuild/pants/issues/12014 which doesn’t have a design). and this would still apply to
./pants update-lockfiles
in the same way i think
folks would call it less often though, you’re right.
👍 1