https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> asked a good question: how do we feel...
# development
h
@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)?
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.
As explained in that thread:
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->repository.pex, instead behaving like approach 1) of no locks but with --constraints set.
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
b
1. is such a win IMO
h
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
b
Personally, I dive into the generated docs as they are the closest source of truth. Others likely have different vectors of attack
👍 1
h
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)
🙌 1
b
FWIW We're doing the opposite because it's all we had the ability to do pre-resolves. A lockfile as a constraints 🙈
h
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
b
Yeah I think a very long tail of deprecation allows people time to find their opinions/voices
👍 1
w
it seems like the deprecation heads in the right direction, so 2.10.x would probably work for it.
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
h
one other consideration though: we have one other significant deprecation for Python users in 2.10.x
Which is? Ah, python macros?
w
macros, right?
coke 1
h
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
✅ 1
w
i think that we could probably land the deprecation on main for 2.11.x, but not cherry-pick it.
➕ 1
👍 1
Open in Slack
PreviousNext
Powered by