My main concern with a separate process is that as things stand right now, even core developers are quick to jump on the packaging ecosystem, sometimes publicly. This is because python has historically focused on other aspects of the language design and considered packaging as either a secondary aspect or as one that isn’t really integral to the language. The result is that there is a strong separation between packaging and the language itself, and it’s underscored by the request to move the packaging process out of the PEP process.
Having a completely independent process will IMO be a symbolic gesture that says basically: packaging isn’t considered integral to the language and isn’t a consideration in language design.
On the other hand there is a wide array of functionality in the standard library and subsections of the core development team have expertise in different areas of the standard library. So the alternative is to treat packaging as any other subsection of the language with a bunch of experts on the particular topic even if not everyone is interested. Certainly it has a massive impact and I tend to think it would be a mistake to discount it from discussions that impact language design.
I disagree with this. I think if anything it’s a nice “break with the past” that indicates that Python packaging is becoming such a priority that we can no longer piggy-back on the PEP process and we as an organization take specifications and communication seriously.
I also think it’s useful for there to be some distance between core dev and PyPA because core dev is focused on CPython, whereas PyPA has to serve the needs of everyone, including projects like PyPy and Beeware, which have their own packaging challenges.
I’d prefer to see more distance between core dev and CPython, frankly.
The PEP process is predominantly about Python language and ecosystem. As the reference implementation, CPython is the baseline for “can it be implemented” as well as a required target, but the language design applies to all implementations. As such, I like having the packaging PEPs be in there, even if the SC establishes an alternative review and approval process for packaging PEPs (which they can totally do, as that’s basically the only power our governance model gives them )
Yep, I agree with Steve - if the PEP process isn’t working for PyPA, it’s the PEP process that needs to change, not PyPA.
The requests I’m seeing in this thread are:
a way to clearly subdivide “Standards Track” PEPs based on their target scope (e.g. “Python language”, “CPython implementation”, “Python packaging”)
having an easy to maintain way for PyPA to specify who is willing and able to sponsor packaging PEPs
(I know the SC having to ratify the standing delegations when they change irks some folks, but that’s been purely a formality to date, and it seems unlikely to become a problem in the future)
I agree with Nick regarding the requests in this thread, for changes to the PEP process.
Looking at how this discussion has evolved till now, it probably makes sense to escalate this issue to the SC, trusting them to make the judgement call on how “broad” the PEP process should be.
I’ll file an issue on the SC issue tracker, requesting the SC for a decision/inputs, in early Jan 2020 (i.e. after the year-end vacations), assuming everyone here is OK with me doing this (holler if you aren’t) and there’s no active discussion here about this, at that time.
Please be VERY clear about what you’re asking about/for. We have no idea who will be on the council come January and so there may be no people on there with any context as to this entire discussion. So please have agreement here on what is going to be asked before making the request, else it’s just going to be a bunch of back-and-forth and questions as to why anything is being asked to begin with if the ask wasn’t agreed upon here already.
My calendar notification about moving this forward, popped up a few days ago.
I’m still going through all the discussions related to this, to try to summarize the situation (and what all we’ve discussed). I’m hoping that it’ll better surface the concerns and trade-offs that we’re dealing with here. I’ll be posting that here once that’s done, for further discussion.
As per my current understanding, there are “smaller” questions here, but the main question we want to ask the SC is:
Should related-but-separate groups within the Python community (like the PyPA) use the PEP process for publishing their interoperability specifications?
(We should definitely provide context about why we’re asking this, which I’m hoping the aforementioned summary+discussion would help provide.)
Is this not the main question we want to ask the SC?
Do we want to ask for something else too?
Does someone else have a better phrasing for this question?
I’m not sure we want to ask the SC whether we “should” use the PEP process. How would they know if it suited our needs? IMO, the only question along those lines that is appropriate would be whether the SC has any objection to PyPA using the PEP process.
If they do, we need to switch to a process of our own (which we’d need to define). If they don’t, then there’s no need to change, but if we decide that the PEP process doesn’t suit our requirements, we can still do so.
A possible supplementary question would be whether the SC want us to use the PEP process - or to put it another way, whether they want to have some level of control over what we decide. My feeling is that they are happy to leave us to make our own decisions, but that may be because the “standing BDFL delegates” (@dstufft and myself, currently) along with the use of the PEP process, are sufficient for them.
Given packaging is such a critical part of most people’s introduction to Python these days, I’d expect this to be the important question and that the SC will likely want the PEP process to be used for anything purporting to be a “community standard” (not simply a feature or design document for a particular tool). That’s certainly what I’d prefer, if only so outside observers have an easier time figuring out what’s officially endorsed and what’s not.
If you think the following is what we want to ask the SC, use the like button below to indicate that. Otherwise, please write a comment describing why you think this is not.
Does the SC have any objections toward the use of the PEP process by related-but-separate groups within the Python community (like the PyPA) for publishing their interoperability specifications? If there are no objections, does the SC feel that it is preferable that these groups use the PEP process instead of a separate process?
It’s missing context, specifically, a clear definition of the PEP process you’re referring to. Also whether the plan is to clone the process and publish everything on a separate site, or if you intend to submit packaging PEPs to the Python SC for approval (and allow them to decide what criteria to use to approve them).
You probably also need to clearly define the scope of (what would currently be) PEPs you are going to take elsewhere. Changes that affect pip may impact the CPython distribution, and so probably need sign off from a CPython “representative” if you don’t want pushback when trying to update the version included with CPython (because someone thinks it’s a breaking change that isn’t appropriate for the 3.8.x or whatever release), while changes that only affect PyPI likely don’t - who decides for each not-a-PEP whether it’s in or out?
Providing that criteria or decision making process (or an intent to develop such a process) along with the question will give the SC something to actually respond to.
@steve.dower: I agree, about the need for additional context.
My thought process was that this question would be asked when presenting the SC with PEP 609. The context on would take the form of a summary of the entire “PyPA process formalization” discussion and would be provided to the SC along with PEP 609 (either as part of the PEP, or along with the issue on python/steering-council for that PEP). That summary would provide the context on why we’re asking this question, what points/concerns have been raised about the PyPA using/not using the PEP process and what “position” PEP 609 represents.
I’d volunteered to do the task of summarizing this discussion but I’ve not been able to make time to do so properly over the past few months. Further, this is not a priority item for me right now and I won’t have the time in the coming days to pick this back up. I welcome others who are interested in moving this discussion forward to write down something to provide the relevant context on this topic for the SC.
I think what’s needed here is a summary of this overall “PyPA process formalization” discussion, which is something that’s been discussed in two discuss.python.org topics (this topic and https://discuss.python.org/t/1776) as well as and two pypa-committers mailing list threads (1, and 2). I’ll try to find my notes from back when I was working on this, but at this point, I’m not even sure how/where I’d made/kept them. If I do find them, I’ll share them here.
)