I’m not opposed to the idea that pip et al should be able to be changed by the PEP process, but historically that was the line we drew in the sand.
The reason we have PyPI follow the PEP process, even for things that aren’t interoperability standards, is because an end user doesn’t really get an option about whether or not they’re going to use PyPI or not [1]. However, if someone doesn’t like the direction pip is going, they’re free to use a different tool.
We’ve had a coouple of PEPs that weren’t about the simple API on PyPI, and weren’t really relevant to things like Artifactory & co.
… which is I guess why I am uncomfortable about the idea of “pip PEPs” - they seem to be acknowledging (and supporting) the idea that users don’t have a choice other than to use pip. Which TBH, goes against all the work we’ve done splitting out parts of pip functionality into libraries - work which was done explicitly with the intent of letting people create alternatives to pip. No-one has actually done so[1], of course, but the option is there.
To my knowledge - I’d love it if someone corrected me on this! ↩︎
This is where we get into project governance questions really.
There’s no obvious inherent reason why any project, pip included, couldn’t use the PEP process for major decisions, but likewise, there’s also no reason that any project needs to use the PEP process either.
Some of this gets into sticky questions about who “owns” a project.
Speaking as a PyPI administrator, I’ve personally always viewed PyPI as “owned” by the community, and I’m one of it’s stewards, trying to do the right thing for the community, even if it’s not the right thing for me personally. To that end, if a PEP got agreement and accepted that I personally disagreed with, I’d still ultimately support it’s inclusion into PyPI because I feel like PyPI is the community’s project, not mine. This extends to the fact that I think that if I (or any of the PyPI admins) were doing things that the community completely disagreed with, that the community could (or at least should) remove us from that project.
Other projects within the PyPA tend not to work or think that way AFAICT. The maintainers of that project generally view themselves as “owners” of that project, and if someone wants to get a change in, they have to convince the maintainers of that project that it’s a good thing to do as even the PEPs aren’t considered authoritative for those projects, if they disagree with one they’re free not to implement it [1].
I don’t think either one of these is better or worse than the other, but that’s generally the mental mapping that I’ve always had and I think realistically describes the reality of how most of these projects operate.
Generally speaking we don’t consider PyPI free to ignore PEPs, the PEPs that haven’t been implemented are mostly not implemented because nobody has produced a good enough PR for them yet, not because we’ve decided not to implement them in spite of their being a PEP for them. ↩︎
Agreed. And personally, I feel that pip is “owned” by the maintainers. That’s not because I’m concerned with “control”, but rather because questions like the scope of pip are really unclear, and there’s no obvious community consensus. As a result, the maintainers are the people who define pip’s scope. We’re not perfect, or even unanimous, but we act as a brake on things like uncontrolled scope creep.
If there was community consensus on “what is pip’s intended scope” then maybe we’d feel more like custodians. But the packaging strategy discussions suggest that we’re a long way from that situation.
I suspect that most tool maintainers feel like that’s their role, and it may be a fundamental difference between what counts as “infrastructure” and what counts as a “tool” in people’s minds.
Right, and there’s honestly some amount of fuzziness to it. I’m the default delegate for PyPI PEPs, so I functionally act in that same role, just through a different process (and it’s not always me, since I can’t delegate my own PEPs, and if I’m not available someone else does it). So you could mimic that by having yourself (or one of the other pip devs) act as the default delegate for hypothetical pip PEPs. That doesn’t feel like it scales very well to every project in the PyPA having their own PEP delegate for their project though.
The flip side of course is that pip is special, even if it’s not quite as special as PyPI is. It’s the thing that is installed by default in Python which privileges it in the community [1], so there is a reasonable argument that it is different than other PyPA projects in similar, but not as clearly defined, ways as PyPI itself is.
In the end, I think it doesn’t really matter. The PEP process doesn’t authority over pip unless the pip maintainers decide to give it authority over pip, and that’s a question for the pip maintainers not the wider community [2], so to me the obvious answer to PEP 704 is that it should be a PEP if the pip maintainers want the PEP process to manage pip. Otherwise it should be limited to standardizing on a name for a “default” virtual environment location, or possibly something more akin to @brettcannon’s proposal for environment discovery.
Though of course, PEP 453 explicitly allows the pip project to continue to operate as an independent project, with whatever decision making process it wants, and itself made the argument that pip is special because the community put trust in it’s maintainers, not because it’s included in Python itself. ↩︎
Though it’s great for the pip maintainers to take the opinions of the wider community into account, and if the wider community wants pip under the PEP process and “community owned” and feels strongly about that, and the pip maintainers want to retain ownership and don’t want to be subject to the PEP process and also feel strongly about that, then maybe it speaks that we need a community owned alternative to pip… but I suspect the answer is most people are fine with whatever the pip devs think is best for pip here. ↩︎