Decide what PEPs fall under Topic: Packaging and act accordingly #2696
Description
Right now, as originally discussed in #2096 , there seem to be two plausible interpretation of what qualifies for the Topic: Packaging label: PEPs that relate to packaging in some direct way, and PEPs that apply to packaging ecosystem (as opposed to the stdlib), and are thus discussed primarily on packaging community fora and accepted/rejected by the relevant packaging-community standing PEP delegate.
In particular, given PEP 632 (PEP-632), on deprecating and removing disutils, was removed from packaging at the request of @zooba for relating to the core stdlib, this would seem to suggest that PEP 453 (PEP-453) and PEP 477 (PEP-477), on ensurepip and its backport to Python 2.7, respectively, should also be removed by the same standard (or, alternatively, PEP 632 restored).
Presuming consensus can be reached prior to its merging, I can implement this on the existing #2690 , given it makes a number of related improvements/refinements to the packaging-tagged PEP headers.
Relevant discussion from #2096 (click to expand)
this is a core Python PEP, not a packaging PEP, and like @dstufft noted, I don't think we tend to modify those after approval.
In that case, as originally discussed on #2656 and done for PEP 632 (PEP-632), maybe we should drop Topic: Packaging from this PEP as well as the related PEP 477 (PEP-477) ? I can do it in #2690 since its closely related to the other changes in that PR (also, your input there on updating PEP 262 (PEP-262)'s status to reflect reality would be helpful).
I don't know on that. It's packaging related in the sense that it is about packaging tools, so if people are looking for things that are "about" packaging, it does belong in the Packaging topic. But it's not a "PyPA specification" in the sense defined here, which is why I said that the normal PEP rules about modifications should apply, rather than the PyPA-specific process. Ultimately, I'm not actually sure what the rules are for when a PEP qualifies as being in the Packaging topic...
Yeah, exactly. That basically comes down to whether a Topic is considered more of a "Category" (i.e. the former), or a "Track" (i.e. the latter). I presented both alternatives at the beginning of the discussion, and both were favored at different points in its evolution; the initial consensus in the Discourse thread was something more like a "Track", but on the PR and naming of the "Topic" header that was eventually implemented (that allows multiple topics per PR), it ended up basically the latter, at least nominally.
However, with PEP 632 (PEP-632) being removed at the behest of @zooba in #2636 (comment) , given these two PEPs basically just concern adding/backporting a utility module from the core standard library rather than PyPA/PyPI standards, it seems to me to not make sense to keep those PEPs but not another very similar one about the deprecation and removal of what was the core packaging module. So, I suggest either removing those two, or adding back PEP 632.
Alternatively, we can defer doing anything here until the authors have a concern with being listed under the packaging index as well or till we see/identify more instances of something like this? In any case, this discussion should move to a separate issue IMO.
I think this is in the same boat as PEP 632, and shouldn't be tagged as a packaging PEP.
As a proposal of the rule I'd use, if we'd let the packaging delegate (i.e. Paul, right now) decide without going to python-dev or the SC, then it's a packaging PEP. Whether something is added to the standard library clearly falls outside of this scope, and so this PEP is standards track and not packaging.