https://pantsbuild.org/ logo
Join Slack
Powered by
<@UB2J9BQA0>, <@U02KAN6061E>: i didn’t do it in <h...
# development
w
@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_constraints
in 
2.11.x
…?
or i suppose that we could wait until we deprecate 
poetry
as well.
h
Yeah 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
yea, 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
What 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
i think that it’s only 100% an easier option for existing users once 
pex
is the default, and i think that it’s worth being cautious about making 
pex
the default. when we’re comfortable doing that, then i think that we will also be comfortable with deprecating the intransitive lockfiles
what the docs recommend is another story i think, as that will primarily impact first-time-setup rather than migration
h
I 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
With 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
Acknowledged. 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
@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
Ashy Thrashy. Makes sense.
😂 1
💯 1
The whole other thing we can allow is updates.
💯 1
h
@bitter-ability-32190 I think has been very excited about that idea
b
Yeah 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
Agree 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
Open in Slack
PreviousNext
Powered by