Should we deprecate

[python].run_against_entire_lockfile

if

enable_resolves

is

True

, and we detect it's a PEX lockfile (once we have the new "everything in a venv" solution)? There's very little reason to keep it around, the only one I can think of is backwards-compatibility (explained in 🧵)

ohhh that's a good point on incremental adoption, I didn't think about that. My concern with that crutch is if people don't realize they should aim to get rid of it, so have a bad performance setting indefinitely --- maybe renaming the option could make that more clear

Well deprecating it is pretty clear 😅

for sure, but maybe we do want to keep it to help people w/ incremental adoption. It lets you ignore issues w/ dependency inference of 3rd-party requirements along with undeclared transitive deps (like when

foo

doesn't properly say it needs

setuptools

for

pkg_resources

) Only nut sure the crutch is worth the risks

Only nut sure the crutch is worth the risks

Or the Pants code bloat. I think the real focus should be on good documentation/tools to help devs navigate through these scenarios.

Speaking of, pex3 lock isn't documented yet on

https://github.com/pantsbuild/pex/issues/1653. I imagine John would appreciate help with it if you were interested

There's like way too much detail in that feature for me to be able to capture it eloquently