asked a good question how do we feel a

Question

< witty crayon 22786> asked a good question how do we feel about deprecating ` python requirement constraints` in favor of ` python resolves` or no locking mechanism

hundreds-father-404 · Answer

As explained in <https pantsbuild slack com archives C0D7TNJHL p1646948835870139> we decided in 2 10 to lean into resolves even though you may need to manually generate the lock

hundreds-father-404 · Answer

As explained in that thread gt The only change from 2 constraints and 4 resolves w manual generation is that Pants is stricter Your lockfile must be comprehensive Whereas with 2 Pex will fill in any unpinned transitive deps for you And with 2 any missing direct deps will cause Pants to not use constraints txt like a lockfile gt repository pex instead behaving like approach 1 of no locks but with constraints set

hundreds-father-404 · Answer

A benefit of getting rid of this code is it 1 simplifies a confusing ` python ` 2 simplifies some of our most complex code `pex py` and `pex from targets py`

bitter-ability-32190 · Answer

1 is such a win IMO

hundreds-father-404 · Answer

You think Note that our guide docs will already only be talking about multiple resolves now But generated docs will still have both only saying to prefer resolves <https github com pantsbuild pants pull 14775>

bitter-ability-32190 · Answer

Personally I dive into the generated docs as they are the closest source of truth Others likely have different vectors of attack

hundreds-father-404 · Answer

Another consideration here is that people might be using a constraints file as a lockfile which we confusingly called it without realizing that it s not a true lockfile For example that transitive deps can be left off By closing that loophole we help people to do a more secure thing Although we also lose an escape hatch

bitter-ability-32190 · Answer

FWIW We re doing the opposite because it s all we had the ability to do pre resolves A lockfile as a constraints see no evil

hundreds-father-404 · Answer

We could set the deprecation to not be over until Pants 2 12 actually And if we get feedback resolves is too strict we can push that deprecation need be So we re not taking away anything here it s only a question of how much we prod people to do a more secure thing Given that I m +1 for deprecation

bitter-ability-32190 · Answer

Yeah I think a very long tail of deprecation allows people time to find their opinions voices

witty-crayon-22786 · Answer

it seems like the deprecation heads in the right direction so 2 10 x would probably work for it

witty-crayon-22786 · Answer

one other consideration though we have one other significant deprecation for Python users in 2 10 x so worth considering whether to wait to 2 11 x based on the total volume of deprecations

hundreds-father-404 · Answer

gt one other consideration though we have one other significant deprecation for Python users in 2 10 x Which is Ah python macros

witty-crayon-22786 · Answer

macros right

hundreds-father-404 · Answer

True true It also seems late in 2 10 s rc cycle to be making a huge deprecation Maybe we stick with the status quo and rely on our docs + release blog to encourage folks to upgrade to the better experience By 2 11 Pex lockfile generation will also hopefully be solid enough for `generate lockfilfes` to Just Work most the time

witty-crayon-22786 · Answer

i think that we could probably land the deprecation on main for 2 11 x but not cherry pick it