https://pantsbuild.org/ logo
h

hundreds-father-404

08/22/2022, 11:35 PM
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

enough-analyst-54434

08/22/2022, 11:39 PM
Always favor the user. They have real problems, we just whine as developers.
đź‘Ť 1
w

witty-crayon-22786

08/22/2022, 11:40 PM
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

hundreds-father-404

08/22/2022, 11:42 PM
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

witty-crayon-22786

08/22/2022, 11:42 PM
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

enough-analyst-54434

08/22/2022, 11:43 PM
I personally consider them the same. Only big orgs have the differentiation.
Hopefully we support the little guys too.
h

hundreds-father-404

08/22/2022, 11:43 PM
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

witty-crayon-22786

08/22/2022, 11:44 PM
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

enough-analyst-54434

08/22/2022, 11:44 PM
And if a team is a team of 5, they all work on the build. I do not discount small!
w

witty-crayon-22786

08/22/2022, 11:48 PM
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

flat-zoo-31952

08/22/2022, 11:49 PM
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

witty-crayon-22786

08/22/2022, 11:50 PM
either data showing the item is legitimately a misfeature, or if it directly conflicts with progress
yea.
đź‘Ť 1
f

flat-zoo-31952

08/22/2022, 11:51 PM
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

hundreds-father-404

08/22/2022, 11:53 PM
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