https://pantsbuild.org/ logo
Join Slack
Powered by
sidenote: <https://github.com/pantsbuild/pants/pul...
# development
w
sidenote: https://github.com/pantsbuild/pants/pull/9826 has only four test failures, which all superficially seem to have the same cause…?! might be reviewable today. 🤞
🍀 3
4️⃣ 2
@hundreds-father-404: what do you mean by “Not yet approving because of the deprecation policy, but otherwise looks great.” ? … btw, i added a description and took it out of draft a little after your comment.
h
Listed under Prohibited Changes:
Changing default option values without a deprecation.
w
hm. in the past that has only applied to options that we expected to have an impact on behavior
h
This has a pretty profound impact on behavior, doesn’t it? Such as no longer being able to do parallel runs It’s overall an enormous win, but also a disruptive one
Fwit, only the codebase admin will probably see this error deprecation message. When they upgrade to 1.29.0, they will decide to either put 
enable_pantsd = true
or 
= false
Beyond compliance with the deprecation policy, the benefit of a deprecation is that it ensures the codebase admin is aware of this really big change. When something is acting differently than before, they are more likely to think “oh, maybe it’s that Pantsd thing?”
We can word the deprecation warning to strongly encourage people to set 
= true
, of course
w
i’m pretty torn on this.
it feels like a good idea to warn people that it is happening, but if we start requiring deprecation cycles for things even when they are “supposed to be transparent”, it’s a pretty slippery slope to not being able to ship features without multi month cycles
having said that, pantsd is not “fully transparent”. so on the spectrum, i guess it might make sense.
but the loophole in this point is: if you implement a new feature that changes behavior, but don’t put it behind a flag, you’re good to go =P
h
I’d agree if there wasn’t an option for this + there was full feature parity, but this does take away some capabilities that people currently could rely on like parallel runs. Again, overall, a huge win. And we should encourage everyone to set 
= true
. We’ll update the new docs at https://pants.readme.io/v1.29/docs/configuring-pants to use it too. And soon, it will be the default But, yeah, I think we want the transparency that codebase admins know this change is happening; even if they don’t subscribe to pants-devel or read Slack
w
how would you feel about a middle ground where we warn if the flag is not set, and change the default at the same time?
h
ship features without multi month cycles
Which is why I want much shorter cycles, hehe. Like, start an rc after dev2, not dev4
how would you feel about a middle ground where we warn if the flag is not set, and change the default at the same time?
Eh, I think that sets us up for a dangerous precedent. The deprecation policy prohibits changing the default. I also don’t know if that makes a big difference, at the end of the day. For pre-existing users, we expect them to decide the option either way at the time of the upgrade. For new users, they copy-and-paste https://pants.readme.io/v1.29/docs/configuring-pants without much thought.
w
so, the deprecation policy was developed and put in place when we hit 1.0.0 a few years back
it was recently heavily edited, and we are currently pre 2.0.0
that is not to say that i don’t agree with it. rather, that we need to make sure we are willing to discuss it and decide what is practical when 2.0.0 arrives
h
Definitely agreed that we should be open to changing the deprecation policy. But until we reach 2.0.0, I think we should do our best to follow the spirit of it
w
that actually feels backwards to me. one of the points of 2.0.0 is to actually finalize a large set of changes
the time leading up to 2.0.0 is the time where we would expect more unstability
h
In fact, I realized that 
buildgen
removal was not at all kosher. Yes, it wasn’t marked “API public”, but we were releasing to PyPI. The spirit of that seems to be that we were saying it’s public. (Also, we can’t get rid of BuildFile until 1.31 anyways, so it doesn’t help us much to remove early. I might revert the removal today)
w
perhaps we have been thinking about it differently, but: i have not been thinking that “exactly the 2.0.0 bump and nothing before it is potentially destabilizing”… rather, that 2.0.0 itself is the “end” of the instability for a while
h
the time leading up to 2.0.0 is the time where we would expect more unstability
Agreed for V2 library APIs and V2-only experiences like the dynamic UI, but Pansd impacts everyone, including orgs who have been using Pants for several years. I think it’s fair for them to expect the same level of stability as before, unless they consciously choose to use the alpha V2 experience
that 2.0.0 itself is the “end” of the instability for a while
End of the instability in V2 land. V1 land shouldn’t have ever been unstable.
w
without expending a very large amount of effort to get to 2.0.0, i don’t think that that is realistic.
h
Why do you think so? We’ve been doing it the past 6 months, like deprecating unused backends; changing the defaults for `--transitive`; moving 
--skip
from task to subsystem, etc. It’s slow and annoying, but feasible And it would be less painful if we had stable releases every 3 weeks, rather than every 5-7 weeks
w
because there is a massive amount more stuff that needs to be removed and/or broken, potentially.
and i don’t think that it is realistic that we will do that all in the PR that bumps to 
2.0.0
h
because there is a massive amount more stuff that needs to be removed and/or broken, potentially.
If that’s the case, I think we need to have a candid discussion with the community about the upcoming instability. For example, say “in 1.29 - 1.32, we are not going to follow the deprecation policy. Instead, we will follow this modified policy:”
w
yes, i think that we started that this week.
we need to figure out what it is going to look like.
h
Right, we started asking for feedback from the community on their usage. But we haven’t yet communicated any change to policy or any increasing instability upcoming
w
right, because it hasn’t been decided yet.
the conversation has just started
(here we are, having it, heh)
h
Agreed. So, with the pantsd PR, my point is that we can’t yet start bypassing the deprecation policy. Maybe in a week we can, but for now, we should try to follow the spirit of the policy when it impacts V1 users
While this conversation evolves, one possible short-term thing to land today is having the Pants repo start using pantsd, but not touching the global default, yet. In a week, we can change the global default. We also then have a week’s worth of dogfood. (These are all 1.29 changes, anyways)
w
to be fair, you added that line last week…? this is why i’m saying we need to continue to determine what the policy should be leading up to 2.0.0 vs post 2.0.0
h
you added that line last week…?
Yes, but because we’ve been following it ever since I joined the project two years ago. I only put down to paper how we’ve been behaving and (I think) what users have come to expect
w
In a week, we can change the global default. We also then have a week's worth of dogfood.
What's happening in a week?
h
We will have had the survey results + hopefully have more insight on what 2.0 means and have had communicated with users what that lead-up period will look like, e.g. upcoming instability
w
a few things: 1. I agree that changing the default for --enable-pantsd justifies a deprecation cycle, and will make that edit to the PR. 2. But I think that we need to edit the policy to allow for cases where a flag default change wouldn’t cause “enough” user impact to justify a deprecation cycle 3. It would be good to avoid editing policy while moving it in the future... ie, for policy in particular, try to move verbatim and independently follow up via our usual channels to propose policy changes.
the reasoning for 2 is that we don’t want to discourage adding flags for things, and so i think that we need to be able to discuss whether they need deprecation cycles when their defaults change.
👍 1
Open in Slack
PreviousNext
Powered by