My thoughts on the Packaging PEP process

PEPs
1

I’m catching up on PEP 722: Dependency specification for single-file scripts - #223 after being away for a few days, but basically my main thought is that I still don’t think this PEP is a good idea. It’s clear from this thread that there is substantial disagreement about fundamental questions. The PEP has come down on one side or the other and that is fine as a proposal, but in that situation I think the right thing to do is reject it until we can more fully work through all the concerns raised and their connections to related packaging issues (such as the “pyproject.toml for non-wheels” thing).

I do want to say one more thing in light of the packaging survey results that were discussed earlier. This may sound a bit negative so please anyone who reads it just try to take it in the spirit of those other threads on “doing what is best for Python packaging”. And it’s all, just, like, my opinion, man. :slight_smile:

In my view, the process and discussion in this thread illustrates some of the causes of the problems identified in the survey. Basically the situation is that there is a use case, and someone writes a PEP with a particular approach to that use case. There is then a relatively quick process by which that particular proposal is evaluated. If that PEP is accepted, it then is perceived to be laying down the law for how that use case is to be handled. Tools that do not want to handle that use case in that way then tend to diverge to varying degrees; this often happens because tools are designed to meet a range of needs and sometimes the PEP-official way doesn’t fit well with other things the tools are trying to do.

The end result is that a PEP designed to address a particular use case impacts all future attempts by all tools to address that use case (whether they choose to follow that PEP’s mechanism or not), as well as tools that may not care about that use case but still have to avoid stepping on the PEP’s toes (e.g., for the present PEP any tool that may use or want to use structured comments for anything else).

Having seen a few PEP discussions on this forum, my impression is that a fair number (especially “small” ones like this that are perceived as filling in narrow gaps in existing tools and standards) are approved more quickly than they perhaps ought to be, and I’m a bit worried that that will again happen here.

What I think the packaging survey showed is that people want everything to work smoothly together. To me that means that looking at a seemingly simple proposal like this PEP and approving or denying it “on its own merits” in terms of how it addresses the intended use case is not really sufficient. There needs to be a slower process of examining all the tie-ins of the proposal to other questions about Python packaging to determine if the total state of the packaging world after the PEP will be better — including whether it will be easier to move towards the “grand unified future” discussed in some of the other threads where we do have everything working together smoothly.

So, for instance, with this PEP, we have the question of whether it should use TOML or some other format, and part of the reason is to tie in (or not) with pyproject.toml, and there is discussion on another thread about how to use (or not use) pyproject.toml for “projects” (whatever that may mean :slight_smile: ) that don’t build a wheel, and as far as I can tell that discussion has not reached any consensus, and meanwhile this PEP is proposing a mechanism for specifying dependencies for a “project” (broadly construed, in this case just a single file) but not intending to generate a wheel. There is a complex interconnection there with doubt at several points. That right there is enough for me personally to conclude “the right thing to do right now is nothing”. We should wait until we have a better understanding of those related questions and how they relate, in order to make sure a chosen solution to one fits well with chosen solutions for others. To do otherwise risks creating more awkward seams in the packaging world.

I think this situation comes up a lot in various decision-making processes, not just Python and its PEPs. My little motto here is: “Every decision should be about everything.” That is, every decision has to be sure to take full account of other decisions being made in parallel and (as much as possible) future decisions that will branch out from it. (Of course, I realize not everyone agrees with me on this. :slight_smile: )

I don’t mean by any of this to suggest that the many contributors far wiser and more experienced than me are suffering from hopeless tunnel vision or anything like that. I’m sure all involved are aware that this decision will fit into a larger ecosystem. All I’m saying is that right now my perception is such concerns aren’t playing as big a role in the overt discussion and progress of the proposal as maybe they ought to, and maybe things are getting a bit rushed.

14 Likes
2

Commenting only on these paragraphs – I would say whilst no process is perfect, the PEP review process does try to look at eco-system impact & constraints a PEP would impose – with the PEP delegate or Steering Council having an important role here in judging the relative merits of any proposal. I can’t speak to culture in the ecosystem re seeing a PEP as the be-all and end-all (‘Enhancement’ is in the name, not ‘Final’!), but I have faith that the PEP delegates have considered such impacts.

If there are improvements to the PEP process that we could (reasonably) make, please open a discussion – but unfortunately many things that would be nice (focus groups, usability studies, etc) are constrained by limited resouce – both time and money.

A

3 Likes
3

@BrenBarn Would it be possible to name the PEPs you have in mind (besides 722)? Would that make sense to do so?

4

Needless to say this only amplifies my concerns tenfold.

Since even the on-topic parts of my previous comment have now been hidden away in a post in a different subcategory on this forum, let me restate those here:

  1. There is no urgent need to make any decision on this PEP. Simply implementing some behavior in pipx and/or pip-run will give users most of whatever benefit there may be. If we later decide some other behavior is better, then we can standardize that, and pipx and pip-run and other tools can then change their behavior to align with what later becomes the standard.
  2. There is still deep disagreement about whether the PEP makes the right decision on several matters. It is better to wait and give ourselves more time to think through those issues.
  3. The PEP connects to several other issues (such as “pyproject.toml for non-wheels”), and those issues should be thought about together, and no proposal on any of them should reach the PEP stage which is not part of a coherent solution to all of them.

At the risk of having this post again moved off, let me briefly say that shoving posts under the rug by moving them off thread has severely damaged my trust in the process of evaluating this PEP (never mind any other PEPs, so see, this is still on-topic). It is more important to make the right decision for Python packaging than to “stay on topic”. If we are straying off topic because this PEP connects to other related matters, that is a sign that there is still more discussion to be had, and thus it is too early to make a decision on this PEP.[1] If such issues exist in the PEP resolution process overall, then as far as I’m concerned it would be better to call a complete halt to all PEP decision-making than to simply press ahead and muzzle criticism. The vast majority of PEPs (including this one, so see, this is still on-topic) simply are not urgent and in most cases (including this one, so see, this is still on-topic) it is better to take longer to reach a better decision than to make a quick decision.

  1. If I were the only one straying off topic that could mean I’m just a raving crank, but I don’t think that’s the case here. ↩︎

7 Likes
5

If a moderator indicates that something is off topic in a specific place, don’t continue to do it there. Next time you do so, you’ll be prevented from posting for a few days to cool off.

You’re reading way too much and too negatively into the motivations of maintainers and moderators. They are not some nefarious group out to make things difficult for you, and they are not ignoring on topic feedback. However, they won’t stop the established PEP process that has worked successfully every time someone dislikes something about the process or a specific PEP. And they’re not required to change the process to match every piece feedback, regardless of how much of it you write, or how strongly you word it.

People do successfully leave feedback and processes do get modified. I’d advise looking around and finding how that’s worked in the past, and comparing successful feedback and process development to the style you use here.

15 Likes
6

You had me with your first post. You lost me with your second.

Overall, my take on the background issue is that PEPs are to enhance Python (PEP 1 says part of the criteria of a PEP is that the SC should find it “Pythonic”). I think for Python (the language/implementation) that’s usually more “obvious” (still subjective, but something easier to agree on).

PEPs like 722/723 impact the ecosystem (and in the realm of packaging). They don’t change Python the runtime/language but rather how people interact with Python the ecosystem. The web of tools, and their support of such things. So, in isolation either of them are amazing PEPs which do solve their use case, and reasonably well. But how can we decide what’s “Pythonic” for something that isnt Python (itself)?

I suspect that’s why I think we’re hitting this wall. And that’s where the disagreements are. I’d +1 PEP 722 in isolation. It makes me uneasy though when I overlay it on the ecosystem.

I don’t have a solution either. Maybe the “Packaging authority” will be able to provide guidance while looking broadly. One can hope :slightly_smiling_face:

4 Likes
7

This has a lot to do with the specific line I’ve taken in the main thread (after having shifted my stance somewhat back and forth a couple of times to end up firmly +1). I don’t think that PEP 722 impacts on “the [packaging] ecosystem”, because I don’t think that what it describes is even a packaging concern, per the standard understanding of “packaging”.

At the risk of repeating the argument:

I would be happy if any given package-management suite didn’t do anything explicitly to support PEP 722, because the things that are accomplished by having such a standard, are not the reasons why I use Poetry. The most relevance that I can see of a PEP 722 dependency list to “packaging” is that it could be used to generate a stub TOML project file, incidentally, as a part of migrating from “not needing packaging” to “needing packaging”. And once such a stub exists, everything else in any given package-management suite works the same way as before.

8

Making that decision is the job of the PEP delegate. A council won’t change that, it will just mean that the council makes the decision, not the PEP delegate.

If we as a community can’t agree that someone has to arbitrate on debates like this, we might as well just all do our own thing and give up on having standards at all.

1 Like
9

First, just to be clear, I apologize if I implied that anyone was acting in bad faith or with ill intent or anything like that. That wasn’t my intention at all. I don’t think that anyone is being nefarious about anything. I also think that broadly speaking everyone involved is trying to make Python packaging better. It’s just that, inevitably, we disagree on how to do that and maybe have slightly different priorities on some of the sub-goals of that larger aim. I have nothing but respect for everyone in these discussions.

I don’t have any immediate problems with the formal PEP process per se. My concern is more with the informal, cultural tendencies that have developed within that process. My original post being split off into its own thread is an example of that. I don’t see anything in PEP 1 that says discussion must be laser-focused on the technical merits of the PEP, nor do I see anything saying that discussion of related but distinct issues is always allowed. Personally, as I’ve mentioned on other threads, I do not see extended discussion as merely a problem or a distraction from a goal of “moving forward” with a specific proposal. Extended discussion that raises questions about the relationship of the proposal at issue to other questions is valuable; it is a sign that there is a space of possibilities that needs to be explored and navigated before any decision is made, or maybe even before any concrete proposal is made.

I think that, with regard to packaging PEPs at least, a more liberal interpretation of on-topic-ness would be beneficial, because (as has been said many times by me and others) a large part of the problem with packaging is not with any single part but with the aggregate effect of having many separate parts, and the relative lack of unification among them.

In that context, it seems to me that trying to consider a packaging PEP on its narrowly construed “technical merits”, excluding connections to other open questions, etc., is like trying to discuss how to build a boat without talking about whether it will be launched in the open sea or on a river, or what kind of weather conditions it may encounter, instead focusing only on the shape of its hull, the height of the mast, and so on. It makes no sense to consider those in isolation because the structural design of the boat is entirely contingent on the environment in which it will be used. Likewise, in my view, issues of the overall packaging ecosystem cannot be separated from discussion of individual proposals, because that ecosystem is the environment in which every such proposal will eventually live (if it is accepted).

5 Likes
10

This is a good point that I had been pondering as well. I think that, in the case of PEP 722, the issue I see is that the level of disagreement about fundamental questions was such that it made me think it was premature to even consider something as specific as a PEP. This isn’t a criticism of you or the PEP, since of course you have no way of knowing what the response will be ahead of time.

All it means is that, to me, the mere fact that a PEP was proposed does not in itself automatically mean that it can or should only be considered on its technical merits. In my own thinking about some of the recent packaging PEPs, a common conclusion I reach is “too many doubts, needs more exploration of the space of possible alternatives”. When this is my feeling, it means I don’t care so much about the specific technical merits of whatever the PEP proposes; what I care about is all the other things that might have been proposed instead. This is typically covered in the “rejected alternatives” section, but I think quite naturally that section is often not as detailed as the PEP’s main proposal.

Of course, this decision (that there are too many unresolved doubts) can still be made by the PEP delegate, but I get a bit antsy when there is a proposal with a lot of disagreement that is already at the PEP stage where it could be accepted and actually become “law”, so to speak.

As I mentioned on some of the other packaging threads, what I tend to think is needed in packaging right now is more discussion before anything even reaches the PEP stage. Then a PEP can be written to codify the consensus of that discussion.

1 Like
11

But the discussion would never have happened without a PEP having been submitted!

What I think is that there’s currently far too many people interested in only discussing things, and not in actually writing or improving tools that users need. I’m particularly frustrated by the people who use the “there’s too much choice” message from the survey as an excuse to shut down all sorts of innovation and improvement, because “we need to decide what the ultimate solution will look like”. Frankly, at this point I feel like I’m going to be burned out long before we get to that point, so why should I even be interested in investing so much of my personal time, energy and emotion into something I’ll never benefit from?

If PEPs are solely for recording consensus, we’ll never solve any of the really difficult questions. We’ll just discuss everything to the point where everyone is too exhausted to care, and then the best we can hope for is that someone who still has the energy to write a PEP will get their proposal accepted by nothing more than attrition.

Rubber-stamping consensus is not what the PEP-delegate role is for. It’s not what Guido did as BDFL, nor is it what the SC does now, and the PEP-delegate role[1] is based on that model.

Yes, I’ve personally always preferred to get consensus when possible. But I’ve always been very aware that if consensus isn’t possible, I make the decision that some people will hate. That’s why I’ve always been as open as I can about why I make the decisions I do, and why I actively participate in as many discussions as I can. It’s not to further my own agenda, but to make sure that we get as close as possible to consensus whenever we can, and when there’s a choice that has to be made, people can at least accept that they were heard, and they understand why there was a choice to make, and the reasons it was made the way it was.

People can dislike the way I’ve handled the role. I’m acutely conscious that I’ve made mistakes. But I do it because I believe it’s necessary, and someone has to be prepared to take it on.

And finally, I’d point out that your whole point here is that “maybe it’s premature to be making a decision”. And yet, you seem to be trying to push for a change in process, when there’s already work in progress to look at the formation of a packaging council. So maybe it’s premature for you to be trying to get the existing process changed, when the discussion about how to change the process is ongoing, and has been for months, and you were actively participating in that process. Is it too much to ask that you wait for the results of that, and accept that we continue with what we have in the meantime?

  1. and, I hope, whatever the packaging council ends up looking like ↩︎

14 Likes
12

I suppose PEP 1 does not regulate how Discuss moderators handle off-topic tangents, even for the PEPs category.

1 Like
13

Nor should it, IMO. Mods shouldn’t have to moderate differently just because of the category :slight_smile:

3 Likes
14

I see your point, although I’ll note that my initial post here wasn’t (at least intentionally) trying to propose any major change in PEP process per se, just a slight shift in how the process plays out (e.g., the relative weight of different factors in the decision). To be honest the main thing that makes me think greater change may be needed is simply that a post like that one (the first one in this thread) is considered off-topic in a discussion of PEP 722.

The essence of what I’m saying is that I didn’t and still don’t consider that post to be off-topic in the thread it was originally in. It is an explanation of reasons why I oppose that PEP, and that is on topic for the PEP discussion. Yes, some of those reasons are the same reasons why I have opposed past PEPs or might oppose future PEPs; yes, perhaps the way I framed those reasons was a bit long-winded; yes, perhaps I even screwed up and gave the impression that I was attacking individuals involved in the discussion (which I didn’t intend to do, and for which I have apologized); none of that changes the fact that the post is explaining reasons I oppose that PEP and so is on topic for discussion of that PEP. I’m abiding by the moderator’s decision to the contrary, but I still think that decision reflects a narrow view of on-topic-ness which hinders rather than helps PEP discussion.

15

Thanks for making this comment, as it forced me to go back and investigate my statement. And I have to say that I need to temper my statement somewhat.

What I originally said was:

a fair number [of PEPs] (especially “small” ones like this that are perceived as filling in narrow gaps in existing tools and standards) are approved more quickly than they perhaps ought to be"

I guess my revised statement would be that some PEPs, especially small ones, are not approved too quickly per se, but rather are approved as small changes when it seems to me the situation would benefit from exploring some bigger changes. This is in line with my view (expressed before on other threads) that some of problems people perceive with Python packaging are unlikely to fixed by small, incremental changes. Making these changes is good in the sense that they improve the situation, but I’m a bit worried that focus on such changes can cause us to “climb a small hill” towards a local maximum in the packaging space, when what is needed is an expedition to a taller mountain.

Examples of some of the PEPs I had in mind are 643 (sdist metadata), 658 (static metadata), 714 (fixing static metadata), 685 (name comparisons for package extras) and 700 (additional fields for PyPI simple API). From looking at the relevant discourse threads I see that the time for consideration of these PEPs ranged from 11 days (PEP 685) to about five months (for PEP 627).

To be clear, I have no quibble with the content of any of these PEPs. As far as I can tell they are good changes. Some of them (like allowing metadata to be served separately from wheels) seem like great changes. I’m not in any way criticizing anything the authors of these PEPs did or anything in the way the discussion was handled.

The thing is that I’m always left with the same question: will continuing with changes of this kind, at this level of specificity, ever lead to a situation in which the fragmented world of Python packaging is unified and users no longer have to even worry about navigating a confusing landscape of tools in order to accomplish their goals?

From this perspective, even with some PEPs that had a longer discussion period (such as PEP 668, externally-managed, which was discussed for over a year), I remain uncertain whether the problems they were attempting to resolve have actually been resolved. This is, again, not because the PEPs have anything wrong with them, but just because the PEPs address only small slices of the fragmentation problem. And even that isn’t a “problem” with the PEPs either.

The PEP process is focused on proposing specific, individual changes to specific standards and tools, but there is a larger-scale trajectory traced by those individual changes considered in aggregate. Apparently consideration (or at least too much consideration) of that trajectory is considered off-topic in discussions of individual PEPs. But from my perspective that trajectory is far more important than the details of any individual PEP, because the fragmentation problem is far more important than any of the specific packaging mechanisms that compose it.[1]

Until the recent “strategy” discussions, it seemed there wasn’t so much of a clear space for discussion of such “meta” packaging issues. I’m glad those strategy discussions have begun. But I think where I differ with some others here is that it really seems to me that, now that some of those big questions are out in the open, it would be beneficial to consider them as part of every packaging PEP discussion.

In short, in my mind, consideration of “how do we want Python packaging to be, overall” is always on topic in discussing any packaging proposal.

Perhaps this post has wound up being just more of the same from me, but I did want to post it in order to respond to the quite apt request that I back up my point with reference to actual PEPs, if only to admit that to some extent my backup is inadequate. In looking over a bunch of PEPs to find ones to mention in this post, I realized that quite likely many people would disagree and just think “those PEPs are all fine, there is no problem whatsoever, the process is working”, as well as “let’s not let the perfect be the enemy of the good”. So I wanted to try to show how I think the PEP process can be “working” while still maybe not moving us any closer to solving the fragmentation problem.

  1. I won’t rehash here all the dimensions of this, but, for instance, considering the Python version as a dependency like any other, handling non-Python dependencies, and shifting to a no-system-Python-everything-is-an-environment model are examples of the kinds of things that I feel are frequently relevant. ↩︎

3 Likes