What is the story around updating dependencies? Li...
# general
What is the story around updating dependencies? Like lets say I’m using a requirements.txt for the whole monorepo and I want to update all the dependencies (and not because I am dependent on new features, I just want bugfixes, security patches, etc.). Do I just re-lock and that updates? Is this something that I have to deal with out of band with pip, poetry, or pipenv?
Yes, when you re-run
./pants generate-lockfiles
you will get the latest compatible versions for every distribution in the lockfile, satisfying all provided constraints (from requirements and transient dependencies etc).
👍 1
I’m working on a feature for Pants, that may make this more clear: https://github.com/pantsbuild/pants/pull/17347
That is nice!!! It would also be good to make it clear in the docs. I expected to find it in the third party dependencies section after “Teaching Pants your “universe”(s) of dependencies” or in the “Lockfiles” section.
thanks for the feedback 🙂
I see the docs does not explicitly mention this, so assumes some pre-existing knowledge of how lockfiles are implemented.
Even knowing what lockfiles are and having written a parser for them it’s still unclear. poetry, pdm, and pipenv all have named “update” commands. pdm has like 20 options when you do
pdm update --help
and poetry has 5 ish. So — coming from those other tools — it’s surprising to not see an update command and to see that the command that does do upgrades has like 1 option.
Ah, yes. There’re currently no options for “managing” your dependencies with Pants commands/options. Only regenerating the lockfile, and there’s not much input to have for that process alone 🙂
That is, to add/remove change constraints/pins etc will be you editing your requirements.txt file or other using an editor or some such
Hi, @curved-television-6568, the screenshot in the PR above looks cool! A question though: Does Pants offer a gradual lock mechanism? (that is, accelerating a subsequent lock based on a previous result). I’m asking since locking in my repo takes about 28 minutes, and that’s with a
file that helps guide the resolver. For context, the old build system also took a long time and needed that aforementioned help to be able to succeed in a lifetime of a person. The repo has ~55 packages with 172 direct dependencies, and 139 indirect dependencies.
Pants does not, currently. Pex however does (the tool Pants relies upon for generating the lockfiles for Python) so it’s a matter of implementing the plumbing to get this to work.
pex3 lock update --help
for option `-p`:
Copy code
                        Just attempt to update these projects in the lock, leaving all others unchanged. If the projects
                        aren't already in the lock, attempt to add them as top-levelrequirements leaving all others
👀 1
I think this is generally tracked by https://github.com/pantsbuild/pants/issues/15704. As with most issues, the biggest issue is figuring out the design and ideal UX. Like what should the CLI commands be, for example. Feedback definitely welcomed!
👍 1
Chiming in as the Pex maintainer. Issuing an
update -p
does not in fact get you gradual lock. Its a slow global lock just like before, but constrained. To do a gradual lock Pex will need to gain the ability to mutate a venv populated with the old lock.
👍 2
Only that will drop lock times.