Is it possible to get a pip friendly version of Pant's lockfiles? When the lockfile is regenerated after a new input or package upgrade, it would be easier to do something along the lines of pants export_constraints && pip upgrade rather than pants export venv && copy/replace.

You can ask

pex

to convert the lockfile to a

requirements.txt

file. I forget the exact command, so you'll wanna poke around `pex`'s CLI. I also have a separate Pants resolve for my tools, and then declare a

pex_binary

for each tool, so I can run them in Pants. So for me the command would look like

./pants run 3rdparty/python/tools:pex -- <pex_args>

. Would recommend

... it would be easier to ...

@nice-florist-55958 is the difficulty slowness of the export afresh?

Yah exactly. The first time someone's env is setup, use pants export. But then need a fast way to automate updating that exported venv whenever the lock is regenerated, especially for very large ones. Will try out the above suggestions. Maybe whatever turns out to be the best option could be baked into options for generate-lockfiles or export goals?

There are old issues filed against Pants / Pex to support mutating a venv. That's really what's needed here. Those issues stem from venv mutation being much faster for Pip in practice let alone Pants and Pex.

in the mean time, this (and the rest of that thread) might help: https://pantsbuild.slack.com/archives/C046T6T9U/p1657568306722129?thread_ts=1657567981.656089&cid=C046T6T9U

@polite-garden-50641 FWIW you can make the PEX call using pants so it's reproducible and doesn't dirty system deps if you do the tools-resolve mentioned above

so I do this in CI, in a dedicated GH job to run pip audit, in my scenario, for this I want to avoid bootstrapping pants in that job just to run export, doing a pip install for pex,pip-audit and then running them is much faster and more light weight.

In my case, I want other devs to run the command, so the portability of a single command is invaluable. It all depends on the use-case

agreed. but this is a CI job that devs never run locally...

Sorry haven't had time to get back on this, just chiming in w/ three more points that came to mind: 1. May be good to have a pip-sync (see pip-tools) like feature, in case people mutate the venv directly such that its resolve would diverges from Pants' 2. Can the lockfile for a

pex_binary

target be exported (for metadata compliance purposes) 3. Can the list of requirements for a

python_distribution

target be exported (same reason)? This list should include first-party distributions (that are now third party from the package user's perspective) and third-party distributions, but not transitive (see this https://pantsbuild.slack.com/archives/C046T6T9U/p1651234825508789 for some discussion). (As an aside, I'll point out something I learned from testing: Pants will not complain about incompatible resolves if a

python_distribution

has dependencies w/ different resolves, so you can easily end up with a setup.py that has incompatible requirements -- understandably Pants does not attempt to build a lock for a

python_distribution

as that would probably be overkill, but it might want to check that targets all have a compatible resolve, or provide options for all behaviors?)