Maybe so. The PEP is firmly stating that installers “must” install to
__pypackages__ by default when present. That could indeed be construed as “deciding the UX”. I suspect @kushaldas might have reservations, though, as having
__pypackages__ used by default is fairly much the point of this PEP at the moment.
On the other hand, what I’m concerned about is the PEP specifying enough core interpreter machinery to let clients (such as installers) implement the layout without needing to write their own implementation of the spec. That’s definitely not a UX matter IMO.
Whoops, sorry. I missed that detail. However what I was trying to say was that if the PEP said that installers can read the layout from sysconfig in such-and-such a way, PDM could have used sysconfig and been protected against such a change (…although because the PEP isn’t implemented in sysconfig yet, that’s not actually an option, but hopefully my point is still clear).
On reflection, this statementg comes across as more combative than I intended, and as such isn’t helpful. My apologies.
What I was trying to say was that this PEP reads a little like an uncomfortable mix of a core Python PEP (a description of a new feature that will be implemented - usually by the PEP author - in a specific CPython release) and a packaging interoperability standard (a requirement that all packaging tools work in a common way, to ensure that they work together).
Without the packaging standard side, the core feature is fine, but may lack sufficient value. I’m essentially neutral on whether the core feature goes in.
On the packaging side, though, @pradyunsg is right, this is getting terribly close to the question of whether standards should dictate the UX for individual tools, which is not something they have traditionally done. Furthermore, packaging standards don’t have the force of “you must do X” (there are usually multiple tools, each with volunteer maintainers and their own priorities), but rather “if you do X, you must do it this way”.
The packaging side of PEP 582 is difficult because:
- It specifies behaviour which installer maintainers may well have opinions about, and the maintainers of a particular installer may not be in agreement (e.g., pip) or may even disagree with the proposal (e.g., conda). So consensus is hard because there’s no clear view of what “the pip maintainers think”.
- It leaves a lot of the work of designing the implementation details to the tool maintainers, and doesn’t even offer a firm level of support from the Python stdlib, in terms of interfaces and APIs guaranteed to be present. As a result, the implementation could be a significant effort, and could easily get lost behind other, simpler and equally high priority tasks (particularly in small volunteer teams).
- It targets a specific Python version, which doesn’t necessarily match with the release schedules or the resource constraints of packaging tools.
If the PEP came with a reference implementation for pip, in the form of a PR, then a lot of the difficulties here could be bypassed - implementation resource is reduced to review and acceptance (or rejection!) of an existing PR, support of the PEP could be a matter of tool maintainers agreeing a consensus view for their tool “offline” as part of PR review, and timescales could be handled by targetting the PR at a particular release. But without a PR, there’s a lot riding on a fairly unspecified amount of work happening in a timely manner, and I think the PEP needs to be written to cover the possibility that this simply doesn’t happen.
But that doesn’t answer my question. And given the responses that have come up from people familiar with conda, the PEP really should note that conda is unlikely to implement this PEP, and address how the arguments change given that (for example) all three of the bullet points in the motivation section will remain unsolved if we accept that people could turn up for a course with either conda or the standard distribution of Python installed.
Maybe the simple answer here is to drop the whole installer side of the PEP and simply concentrate on the core change to how
sys.path is calculated. The arguments are weaker without the installer side, certainly, but they remain valid if you phrase them in terms of “if installers choose to support a
__pypackages__ install method, …” And once the core feature is in place, installers (and other tools like PDM and pipx, or even pip) can experiment with UX without needing people to install and invoke the current support wrapper. Timescales are longer, and more uncertain, but that’s pretty normal in the packaging world, unfortunately