https://pantsbuild.org/ logo
Join Slack
Powered by
When running `generate-lockfiles` for a python res...
# general
l
When running 
generate-lockfiles
for a python resolve, is there a way to tell pants to do only the smallest subset of necessary updates on top of the existing lockfile necessary to fulfill all the constraints?
Some more details on the expectations and observed behavior that led me to ask this: I recently added a package - tabulate - to the requirements.txt for our default resolve. It has no dependencies of its own. Then I ran 
pants generate-lockfiles --resolve=default
. I think what I expected to see was only a new entry for "project_name": "tabulate" under "locked_requirements". But what I saw instead were upgrades to a number of other requirements, and nothing about tabulate:
Copy code
05:22:48.81 [INFO] Wrote lockfile for the resolve `default` to 3rdparty/py/default.lock
                                                                  
Lockfile diff: 3rdparty/py/default.lock [default]
                                                                  
==                    Upgraded dependencies                     ==

  aiobotocore                    2.11.1       -->   2.11.2
  boto3-stubs                    1.34.33      -->   1.34.34
  botocore-stubs                 1.34.33      -->   1.34.34
  markupsafe                     2.1.4        -->   2.1.5
  pip                            23.3.2       -->   24.0
  pytest-docker                  3.1.0        -->   3.1.1
  types-pytz                     2023.4.0.20240130   -->   2024.1.0.20240203
Digging into the lockfile, I realized that there were no changes for the new direct requirement on "tabulate", because the same version was already in the lockfile as a transitive dependency through a few other packages.
But I believe this means that I don't need to update the lockfile at all. I think what I would like to be able to do would be to run a command that confirms "yep, no changes needed for the specified set of direct dependencies!" and/or do the smallest set of changes necessary. Is that possible already? Or is it a reasonable feature request?
h
There will be such a way soon, hopefully. The features necessary for it now exist in Pex (the underlying tool Pants uses for generating lockfiles, among many other things).
🙏 2
🙌 2
https://github.com/pantsbuild/pex/issues/2344 tracks the last bit of work for this on the Pex side. Pants doesn't actually have to wait for this, and could replicate this logic instead, but it's probably better not to have to do that. So we'll likely build this into Pants on top of #2344.
➕ 1
l
Yep, that makes sense to me, thank you!
h
Watch this space! Or rather, the release notes for upcoming Pants versions
I don't yet know which version this will be in. Not the upcoming 2.20.x, but maybe 2.21.x.
👍 1
l
By the way: In my specific case, where I was adding something as a direct requirement that already existed at the right version in the set of all requirements, it (seems to?) work fine for me to only add it to 
requirements.txt
, and leave the lockfile unchanged. I'm not sure if this is best practice, but it seemed reasonable to me, to avoid updating unrelated dependencies and risking that I break other targets, when what I'm doing should be a no-op.
c
By the way: In my specific case, where I was adding something as a direct requirement that already existed at the right version in the set of all requirements,
I think that's fine in this case. Pants and Pex have slightly different accounting of "what was the input to the lockfile" so there is probably some corner case lurking in there... but Pants is currently pretty conservative about "out of sync" like problems
🫣 1
🙏 1
6 Views
Open in Slack
PreviousNext
Powered by