https://pantsbuild.org/ logo
Join Slack
Powered by
Any opposition to keeping `[python].resolve_all_co...
# development
h
Any opposition to keeping 
[python].resolve_all_constraints
until Pants 3.0 (but deprecated)? Originally, the plan was to remove it.
We've had so much whiplash with Python lockfiles, it seems like a good courtesy for users. Because it's deprecated, it will be clear new users should avoid it I've finished refactoring (thanks to @rule_helper!), so the impact to understanding 
pex_from_targets.py
is actually pretty minimal now. Note that we will always need to keep around a lot of the relevant code with how to subset via 
--repository-pex
because we decided to support manually managed requirements.txt-style locks
cc @witty-crayon-22786 and @bitter-ability-32190 who I think were both looking forward to deleting the code, along with me. and cc @flat-zoo-31952 and @enough-analyst-54434 who I imagine will agree w/ keeping it
e
Always favor the user. They have real problems, we just whine as developers.
đź‘Ť 1
w
deprecation length is a very nuanced tool. how to choose 
2.N+1
vs 
3
is unclear, but is something that i think @flat-zoo-31952 was going to be looking into based on the audience
âž• 1
this is not an end-user facing feature: rather, an admin. maybe that influences this.
h
let's say we choose 3.0 today, but realize in a year that this feature blocks some important change. Thoughts if we could change the deprecation from 3.0 to 2.40 etc, given several releases for that to happen?
w
but if there is not a concrete upcoming feature that will motivate further changes to 
pex_from_targets
, i wouldn’t be hunting for things to deprecate anyway.
đź‘Ť 1
e
I personally consider them the same. Only big orgs have the differentiation.
Hopefully we support the little guys too.
h
this is not an end-user facing feature: rather, an admin. maybe that influences this.
I think the most important thing here is that 3rd party requirements are complex and frustrating to deal with. We shouldn't force you to migrate, but we should encourage you to use the newer and safer thing
w
I personally consider them the same. Only big orgs have the differentiation.
i don’t think that that is true. if a team of folks work in a monorepo, only one of them is going to land the upgrade PR.
to the extent that we are used by single-person teams, then maybe.
e
And if a team is a team of 5, they all work on the build. I do not discount small!
w
not in my experience… even at that size you have specialists. but regardless: i don’t think that that means “admin vs end user” is not a useful consideration… just that it becomes less useful for very small teams. grey area.
f
I think everyone will have some version of "admin vs user", even small teams will have 1 or 2 team members that "get it" much more and drive adoption, perform upgrade cycles, decide how Pants gets used. But even admin-only deprecations should be motivated by concrete issues: either data showing the item is legitimately a misfeature, or if it directly conflicts with progress... this is what i'm going to recommend anyways.
w
either data showing the item is legitimately a misfeature, or if it directly conflicts with progress
yea.
đź‘Ť 1
f
I am this admin for a large-ish org, and it still takes me time to my head around changes, even ones that are fully backwards compatible and unambiguously positive. Just learning I can do things a new way takes time. So no matter the user type, we should try to make life easy on them.
đź‘Ť 1
h
either data showing the item is legitimately a misfeature, or if it directly conflicts with progress
• misfeature: no, it's valid. only much worse than 
[python].enable_resolves
• progress: not really, only makes our code harder to deal with. but it's factored well now
👍🏻 1
Open in Slack
PreviousNext
Powered by