Why is the process for PEP 722 in such a rush / impartiality of PEP delegate in question

PEPs
1

With all respect for Brett, how is it that someone with an explicit stake in this through their employer (and who knows what other related constraints about product delivery, timing, etc.) can become the PEP delegate on this?

The SC has rules to prevent over-representation to any one company, and now we’re asking one person with a definite stake in the outcome (rather than a more neutral party) to make this decision for the rest of the Python world at large?

I really mean no disrespect to @brettcannon here, but this kind of process failure is a concern to me. Unfortunately we don’t have a PyPA council yet, but I find it hard to believe that there could not be a similarly knowledgeable yet more neutral decision maker (or perhaps defer the PEP to the SC directly).

I might not have commented on this under other circumstances, but I find this kind of attitude concerning. This sounds a lot like “Be glad I’m even considering an alternative and giving you a week to write it”, and if so, I would very much not be glad.

How is it that this use case, that has not been covered for years, suddenly needs to be solved now, with a forced choice between PEP722 and whatever alternative will “generously” be considered? Rather than taking some more time for designing this coherently and not adding to the pile of things in python packaging that are bolted on?

Is it because VS Code would like to have a certain feature with an official stamp of approval? Probably not, and it’s just that @pfmoore asked Brett to fill in since he cannot approve his own PEP.

But outside of a handful of people, we cannot know that, and forcing a quick decision here does not improve the optics. From a wider POV (e.g. users asking us to unify things), this rush makes no sense to me, and IMO it’s harmful to the packaging ecosystem (basically a big +1 to @BrenBarn’s post that got separated into its own thread, as well as some of @jeanas thoughtful points on the long term view).

Please consider recusing yourself @brettcanon.

20 Likes
2

I don’t like that this topic was split off. The question about who makes the decision for that PEP is as pertinent as the content of the PEP.

3 Likes
3

I think Brett already answered this well in the post you’re replying to: PEP 722: Dependency specification for single-file scripts - #210 by brettcannon

I don’t see how Brett’s work on VSCode is anything but a positive here. It’s not like that pushes him towards any particular solution, beyond having a solution.

Note that VSCode could just as well unilaterally just do something nonstandard (just like pipx and pip-run already did). Instead, they’re participating with the community, spending their time to ensure multiple proposals are considered, and arranging funding for user studies.

As Brett already mentioned, the “one week” wasn’t a diktat, but a first step in a conversation between Brett and Ofek. See the post you’re replying to.

Like Brett already said, if Paul thought someone else would be able to spend more time or do a better job than Brett, he could ask them to do so. Note that if you’re questioning Brett’s ability to make a fair judgement, you’re also questioning Paul. You’re well within your rights to do so, but if so you’re better off trying to make a stronger case to the Steering Council as to the process failings of PEP delegation. I’m also confused as to what your object level objections are… It seems you prefer PEP 723 (as do I), and we live in a world where PEP 723 exists and will be considered — if there’s not an object level failing here, I’m not sure there’s much of a case.

I do think the “the fact that I’m willing to even consider” sounds poorly phrased, especially out of context (and I would be unhappy if Brett hadn’t seriously engaged with alternatives, in discussion or in PEP). But there is still truth in that statement. Time is finite, but in my experience Discuss threads on Python packaging are infinite. At some point, if you want to make change, you have to bound your effort. 2 PEPs after 300+ posts is already a lot of effort!

Finally, I’d echo everything David said in My thoughts on the Packaging PEP process - #5 by davidism , especially the part about reading negatively into folks’ intentions and motivations. Brett has been a steward of the community for far longer than I’ve known to code — if I was Brett, this kind of post would make me just not want to improve things.

22 Likes
4

Thank you for these comments - you’ve said what I would have wanted to say far better than I could have managed - to be honest, I’m extremely close to burnout from the whole debate over PEP 722, which has strayed very far from technical discussions into questioning individual’s motives, and debates over the whole idea of whether we should even be trying to make progress on individual issues.

Can I also say that I’m hugely appreciative of the moderation on this whole debate which has, IMO, been exemplary. Getting the balance between allowing discussion to continue but keeping people focused is an incredibly hard job, and is now also attracting accusations of bad faith (in a different thread than this one). Thanks to @davidism in particular over this.

I hope that the packaging community can resolve our differences and get back to trying to what we all want to do, which is improve the experience for users. It’s a shame that the discussions on the results of the user survey weren’t handled better - rather than giving us a shared goal and a unity of purpose, they seem to have exaggerated our differences and promoted confrontation over co-operation. I really hope that’s a temporary thing and we can find a better way forward. Maybe the work on forming a packaging council can help here, but I have a genuine fear that if not handled well, it might simply divide the community even further. Let’s hope that doesn’t happen.

19 Likes
5

I think you’re misunderstanding my work-related position to this. If one of these PEPs get accepted, VS Code will implement support for it. If neither PEP gets accepted then VS Code simply won’t have a similar mechanism. That’s it. I don’t think that’s having a “stake” anymore than anyone else who may be asked to support any accepted PEP (who, historically, are people that make good PEP delegates because they have intimate knowledge of the problem domain).

Unfortunately your comments around me being named PEP delegate has come off as such. I have been a core developer for over 20 years and this is the first time anyone has ever questioned whether I would put my employer ahead of the Python community. I think my record has shown that I simply would never do that (nor have I ever been asked to by any of my employers, to be clear).

I’m sorry if the tone came off as terse or even rude, but as I said above, your tone has come off as disrespectful to me and it has made me feel like I need to take a defensive position.

No, it’s that we won’t bother with the feature unless there’s something with “an official stamp of approval”. To me, it sounds like you think I wanted to do something in VS Code and then came here to ask for it to be “blessed” so I got some protection by it being official or something, which is not at all the case. I’m sorry if this is sounding repetitive, but I’m not sure how you reached your conclusion around how any of this is being motivated by me being a PEP delegate.

I will step down as PEP delegate if Paul asks me, but otherwise I disagree with your reasoning as to why I shouldn’t be the PEP delegate in this situation, and so I have no plans to recuse myself.

Hence why your comment wasn’t deleted, hidden, or moderated so it couldn’t be shown. But it is a bit of a tangent to either individual PEP and thus can stand as its own discussion point.

BTW I didn’t do the splitting (I’m purposefully not moderating this discussion as I’m too close to it).

Ditto, but I plan to see this through if you and Ofek are.

23 Likes
6

Thank you @pf_moore and @brettcannon for years of stewarding the packaging ecosystem along with a number of dedicated contributors.

There will never be a one size fits all for packaging in any programming language. As a language that interacts well with many languages, such as C, C++, Fortran, Rust and more, the packaging solutions become more complex to meet the needs of the communities.

I think that focusing the discussion going forward on the technical merits of PEP 722 will be most productive and serve the larger community of Python users and developers.

As for specific comments about @brettcannon, I’m disappointed that someone would question his integrity or commitment to doing what is best for the language and community. I’m sorry that this discussion has gotten personal. It’s time to refocus it on the technical merits of the PEP.

21 Likes
7

Agreed, I also got upset on this one, and since I do not seem alone, perhaps a clarification would be in order. (I have no reason to distrust @brettcannon on the basis of his employment at Microsoft, however.)

4 Likes
8

I apologise that my comments have been taken as disrespectful or personal – that couldn’t be further from my intention (and I’d say, my formulation, but clearly that’s subjective).

My trust in any institution is as high as its decision making processes are sound, and as transparently isolated it is from the incentives of its agents. As you can imagine, few institutions hold a high degree of trust for me[1]. Still, that is completely compatible with high respect for Brett individually. So while I’m very happy to apologise for any offence I’ve given, I reject the characterization that I made the discussion personal.

All I’m pointing out is a conflict of interest (and the appearance of one is enough TBH) – which is completely independent of Brett personally or his contributions. I also pointed out at least three other options so the process could move forward nevertheless: a more neutral delegate, wait for the formation of a PyPA council, or defer to the SC.

This is our first collective foray into that area, and clearly many people hold an opinion on this. I’m sorry to hear that people are worn down. I’ll just say that a large part of that discussion has been the finality of PEP 722’s design (fair enough for @pf_moore to stick to an approach of course!), coupled with the fact that it started – effectively – from a presumed-accepted position, and any alternate designs are lucky to get even considered.

It just strikes me as a very unhealthy design approach for venturing in a new problem space, especially given that users are already highly critical of the inconsistencies in python packaging. Both the rush to bless any solution, as well as not taking time for alternatives are IMO profoundly harmful. And while I can truly empathise with someone feeling burned out, it’s still not a good reason to force a decision on everyone else.

Compare that to the SC’s approach to accepting PEP 703, which – while obviously much more impactful – has been to take more time to analyse things, ask questions and weigh the different tradeoffs. That’s why the announcement of intent to approve got unheard of amounts of hearts, because it was a healthy process to try to solve a tricky problem.

I still do not understand the rush here. There’s substantial portion of people (based on the responses and hearts) who think that while the problem is worth solving, the PEP 722 way has problems. Other people feel the same about PEP 723. Forcing a decision now will just disenfranchise one group over the other, aside of course from ruling out a better overall design (that we might still be able to hash out otherwise) for the next several years.

Even if that makes me the bearer of unpopular news, I believe we can do better than that.

  1. humans are just very flawed everywhere, and it exponentiates the larger the group ↩︎

4 Likes
9

I’m not sure what clarification you’re after? I apologized above for the tone. But the fact is, considering multiple PEPs at once is not common. I was asked if I was up to the task to consider another PEP on the subject because of this, and I said yes (although I will fully admit I am coming to somewhat regret it). Typically PEP delegates ask folks to work it out and reach consensus around a single proposal, else it’s easy to simply consider the PEP in front of them, think about whether the rejected ideas would make better sense, and then come back and say, “I reject this PEP, but I would be open to a PEP on this idea, or update the PEP to be about this”. The fact that I am willing to tackle two full PEPs at once is not required of me and was done somewhat to be nice to the other side and because Ofek offered. There’s a reason why Paul pointed out that two PEPs simultaneously doesn’t always lead to good outcomes.

Once again, I have done this all before, so I’m not sure why this is the topic that people have decided deserves questioning me or the PEP process that has been serving us for literally decades.

If you want to pull in the Zen of Python:

Now is better than never.
Although never is often better than *right* now.

People are motivated now, people are willing to write PEPs now, I’m available to be a PEP delegate now. This sort of thing can easily fizzle out, especially with the volume of comments that have already occurred. Plus life very easily gets in the way and people who think they will have time in the future end up not actually having it. I have seen this happen many times over the years, so this isn’t just hyperbole.

I broke a personal rule of mine in reading discuss.python.org on a weekend as I wanted to try and stay on top of the discussion on PEPs 722 and 723. I try to avoid anything that could be triggering and upsetting so I can at least have the weekend to unwind. Unfortunately that didn’t happen and my Saturday was slightly ruined. Luckily Monday is a holiday here, so I will still get two days to decompress from all of this.

I also will be unsubscribing from this particular topic (and anything else questioning the PEP process). I don’t think there’s more for me to say on it and it just isn’t bringing me any joy. If the decision is made to ask me to stop being a PEP delegate then I’m sure I will be told of this fact via other means.

16 Likes
10

I’m going to stay light and neutral, given the context. Hopefully, we can conclude and get back to more interesting topics :slightly_smiling_face:

I myself had some unease reading some of the wording/phrasing of that thread. In most cases, I like to chalk it up to English being an imperfect language (Python is the only perfect one :wink:). Maybe someone is having a bad (or weird) day. In cases of doubt, I assume best intent or ask.

As to the perceived conflict of interest. PEP 1 has a section about it. The example given is “same employer” (I currently work for IBM, so by PEP 1 standards I’m very conflicted :upside_down_face:). I could believe that someone might perceive a conflict of interest here (whether or not there is one, perception is the keyword).

Luckily PEP 1 also gives instructions to those who perceive a conflict of interest and feel strongly about it.

So, I hope that instead of continuing this discussion we can continue discussing the PEPs themselves, and follow the established process, if needed, for any overarching concerns about the process.

2 Likes
11

I mean, I guess this is just a difference of opinion, but that just doesn’t sound that bad to me. The fact that someone was willing to write a PEP does not, to me, say much about whether the time is right to make a decision on it. When is the right time has more to do with how well the overall problem space has been explored. What you’re describing sounds like an approach of “take the first good-enough proposal”, and I lean more towards “fully explore the space of alternatives and pick the best”.

I quite agree with this and it’s basically what I said in the other thread on my own split-off post. As you say, it’s no knock on @pf_moore, but it seems it was a bit early for this proposal to reach the PEP stage.

I think this is a vital point. I didn’t interpret your original post as impugning @brettcannon’s motives in any way.

It’s the same in many governing bodies, most notably, well, actual governing bodies, like city councils and judicial panels and so on. It’s just good decision-making policy to avoid situations where there may be a conflict of interest. That’s not because we think someone is going to cackle maniacally and cast a vote purely for their own selfish ends, but simply because a person with too close a connection to the matter may not be in the best position to evaluate the proposal. And, as you note, even if they can be impartial, the mere perception that they might not have been will color all future impressions of whatever decision they make.

4 Likes
12

Well I’m afraid that given we’re making such a big deal here about how things look, I can confirm that it very much felt like a criticism of me, personally. And in particular it felt like an accusation that I wasn’t acting in good faith, which to be honest is perilously close to violating the code of conduct.

As the packaging PEP delegate, I’m in a uniquely difficult position when I submit a PEP, as the normal process for getting it approved[1] doesn’t work for me. I don’t appreciate people making it even more difficult for me by attacking the process, rather than discussing my proposal on its technical merits.

  1. i.e., do nothing, and Paul will make the decision ↩︎

12 Likes
13

I have no idea what this is referring to, but given that this is attached to a thread based on my post: I categorically reject that there was any accusation of bad faith on my part. In fact I even pointed out how it’s very likely in good faith (but with suboptimal optics nevertheless).

Both you and Brett are decision makers in this (you as packaging PEP delegate, him as SC member and your stand-in for the PEP), which attracts a higher degree of attention and scrutiny. Comments squarely aimed at your role(s) and the process are really not the same as personal criticism.

That said, I apologise if I made you feel that way, that was not my intention.

7 Likes
14

Like @h-vetinari I would stress that the notion of conflict of interest (COI) is pretty much objectively defined nowadays, and pointing a COI should not be perceived as a personal attack against @brettcannon or anyone else. Being able to discuss these topics publicly and serenely is the sign of a healthy community.

Also, having a COI is not an impediment to participating or even making decisions.

21 Likes
15

I’ve been following this thread silently.

I think the two issues here are completely separable: 1) is there a COI, and 2) is the PEP being pushed through too quickly.

I very much agree with @pitrou that a conflict of interest should not in any way be perceived as a personal flaw or character statement - it is simply a fact of somebody’s position as both a decision maker (for a decision that affects others) and someone affected one way or another by the decision.

In general (I am not talking about the PEP process specifically here), the reason to recuse oneself on COE grounds is NOT because one feels unable to make a fair decision, it is to avoid any such accusations - before, during, or long after the decision - because they can be so personally hurtful, and damaging to the community, even when - sometimes especially when - no abuse of any kind has actually occurred.

One consideration in the Python community (I am not sure whether this is truly the case) is that there may be a shortage of qualified PEP stewards, so that people have to serve in the position even when they would “normally” recuse themselves, or else nothing would ever get done. If/when that is true (again, I have no idea whether it’s true in this case), I think the healthy thing to do is acknowledge the inability to find someone else, state plainly what conflicts may appear and why they are not an issue in this case, and move on.

My only comment on this particular case: VS Code (among others) is responsible for implementing so many PEP implications, every single time, that unless something is really special about this particular PEP I don’t think their employees’ involvement is automatically a COI.

As for 2), rushing through the process - IMO there should be no rushing through the process in Python-land, ever. Personal opinion/testimony follows here the PEP process has transformed Python over many years from a language I had basically no interest in using in the beginning, to a language so vastly improved now that it is my default choice for most things. I can’t figure out why other communities don’t copy the PEP process more effectively. As a community member and user, the best feeling I can have is that decisions are being made with a high level of public input and scrutiny, and not just by an “inside baseball” club.

Anyway, I’ll go back to lurking mode. =)

6 Likes
16

That’s an all-too-common situation. Unpaid volunteers are always in short supply, but it’s even stronger when looking at COIs - there’s an automatic and natural correlation between “people who will be affected by this decision” and “people who are well positioned to make the decision”. IMO a potential COI needs to be acknowledged, but it doesn’t have to force someone to step down - and in this particular instance, I see Brett as a perfectly reasonable and well-placed person to make this decision. (But I’m on the very outskirts of this and only reading the posts cursorily for the most part.)

Don’t ask me about my fantasies of a political system that involves a monarch, a set of ministers, and a PEP-like process… we’ll be here all week :slight_smile:

9 Likes