#development
Title
w
witty-crayon-22786
04/06/2022, 11:45 PM@hundreds-father-404, @bitter-ability-32190: i didn’t do it in https://github.com/pantsbuild/pants/pull/15014, but: it seems like we should probably deprecate
requirement_constraints2.11.xor i suppose that we could wait until we deprecate
poetryh
hundreds-father-404
04/06/2022, 11:54 PMYeah I figured that we want more time to let the dust settle on lock file support. I think at a minimum we should deprecate constraints in 2.12 but maybe it's ready to do in 2.11 after all?
There was a thread from I think a month ago when we decided to go with lock files rather than constraints in 2.10, even though lock file generation was not ready yet. The main downside of using a lock file rather than constraints file is that it is stricter because it must be fully comprehensive. That is a good thing but it is taking away a feature from users that let them partially pin
w
witty-crayon-22786
04/06/2022, 11:55 PMyea, but we also added the facility to allow folks to manually generate the lockfile, so in theory everyone could migrate to manual generation in 2.11.x
but yea, you’re right. the transitivity thing is a big difference. probably best not to force people to do that manually.
➕ 1
…and just be patient.
its only really while i’m changing this code that i care about deprecating it, heh. the urge(ncy) will pass
➕ 1
h
hundreds-father-404
04/06/2022, 11:57 PMWhat about deprecating but not removing until 2.13? that makes more clear in our generated docs that this is a subpar experience
Yeah, we can proactively encourage people to reach out if they are having issues migrating. Might be a way to get more feedback. And another avenue to encourage people to upgrade switch to new experience, if they are not reading our release blogs
w
witty-crayon-22786
04/06/2022, 11:59 PMi think that it’s only 100% an easier option for existing users once
pexpexwhat the docs recommend is another story i think, as that will primarily impact first-time-setup rather than migration
h
hundreds-father-404
04/07/2022, 12:00 AMI had a todo to make pex the default in 2.12 this week. Now that we have the performance fix, it seems like in generally better experience than poetry locking. Reminder that poetry locking is very unlikely to work in larger repos due to the transitive dependencies environment markers issue (wow Siri got that all)
e
enough-analyst-54434
04/07/2022, 12:02 AMWith PEX locking, requirements, constraints and locks are all in play and compose. Maybe you're deeming it the case no one will want to have some requirements + a few constraints + generate a lock. But Pex can handle it.
h
hundreds-father-404
04/07/2022, 12:03 AMAcknowledged. I do think we will probably want constraints back in some future, but it is too loaded with history right now to keep around for now because we abused constraints files so badly
w
witty-crayon-22786
04/07/2022, 12:03 AM@enough-analyst-54434: unfortunately “requirements_constraints” is a catchall for “a single global constraints file used as a lockfile”… with multiple resolves supported, we would need to reintroduce constraints files separately per resolve.
e
enough-analyst-54434
04/07/2022, 12:03 AMAshy Thrashy. Makes sense.
😂 1
💯 1
The whole other thing we can allow is updates.
💯 1
h
hundreds-father-404
04/07/2022, 12:04 AM@bitter-ability-32190 I think has been very excited about that idea
b
bitter-ability-32190
04/07/2022, 12:28 AMYeah I can't make a new lockfile from scratch because that would change waaaaay too many versions, and that's too much risk
With sufficient time and bandwidth I can bring everything up to date, and then I can always go from scratch... Probably
And I agree with @hundreds-father-404 on the slow deprecating. Even though we all agree it'd be a load off
c
curved-television-6568
04/07/2022, 5:27 AMAgree with the above. Just noting that I think it's an option also to deprecate something more than one stable release in advance.. as has been hinted above, too
➕ 1