It's surprisingly little code for us to support pex.py installing a lockfile from either Pex's JSON format vs. normal requirements.txt-style. We do still want to change Pants's

generate-lockfiles

to always generate using Pex JSON. But do we think it's valuable to indefinitely let users keep manually generating their requirements.txt style lockfiles, e.g. via pip-compile or poetry export?

I think this question can and should be answered when PEX lockfiles are more mature and stable, no? Until then, I suspect supporting both will be necessary.

True. I was asking mostly to scope how robust we need our PEX Json lock vs. requirements.txt-style lock detection to be

(See my GitHub issue comment, we might be able to punt this on the user and get correctness)

I'm still writing out my reply, but tl;dr is that manually generated lockfiles have no guarantee that lockfile headers are present 😕 https://pantsbuild.slack.com/archives/C0D7TNJHL/p1646791761839639?thread_ts=1646774475.931779&cid=C0D7TNJHL

Wouldn't we know that they're manually generated though now? through the new option?

Ah I don't think it's reliable to rely on reading option settings like that because it presumes that users are regenerating every single lock after they change an option. There is no guarantee of that. You can for example say "I want all new locks to be generated with PEX" via

[python].lockfile_generator

, but not regenerate what you already have. Pants needs to support that imo.

I think thats where the proposed option comes into play, to help bridge discrepancies

what do you mean?

(after "offline" discussion) Now that I know there's a way to migrate my pip-style

reqs.txt

into PEX json and keep the same versions (

pex3 lock create --requirements reqs.txt -o foo.lock

) I'm much tolerable to sunsetting all support of pip-style txt file, assuming users are made aware of the migration mechanism and it works as expected.

I've been trying to figure out why I have a gut feeling of not pushing too hard on a migration script. I think it's because the Poetry lockfiles created atm via

generate-lockfiles

have weird quirks like environment markers. I'm not very confident that we want people using that as the input to regen lockfiles I think it's helpful to offer as an option, but an option that you might not need or want to use

Yeah, I think the main use-case is you weren't using

generate-lockfiles

before, so maybe a solution built into

generate-lockfiles

doesn't make a whole lot of sense 😅