The first part of the motivation for this PEP, the Disabling Manylinux PEP, and the issues I’ve linked to on the PyPA issue tracker (whether as complaints from users, or ideas being thrown around) can probably be summarised as there are specific wheels which come from PyPI which for whatever reason are not what users want to use (manylinux wheels are the example which is easiest to point out, but pywheels is another possible example). I guess the first question is do people agree with this statement, or do we want to discuss specific cases (and/or if this isn’t clear, suggestions about how to word/approach this)?
The second part is that if we take the statement about the wheels on PyPI being true, then what do we do? Running things like auditwheel on upload can help reduce the problem, but that only fixes/blocks new wheels, not existing ones (and auditwheel can only be reactive to problems, so can’t fix issues where a wheel passed when uploaded but would now fail). Users can build wheels from source, but at least in the case of manylinux, the currently built wheels are given a lower priority, so users need to go to extra effort to block all manylinux wheels, even it it’s only specific wheels that are the problem. Users can do things with devpi (or similar) to filter projects on PyPI, but unless we want to start adding blacklist support for specific artefacts (in whichever project, whether pip, devpi or other installers), getting the result users want requires an intersection of these solutions. I currently have a setup with devpi+_manylinux.py which works for me now, but the for now bit concerns me, as the reason I started with the PR against packaging was things broke, and I was looking for how best to prevent that in the future. The local wheel tag idea makes it simple to effectively blacklist a specific problematic wheel, by simply building a wheel which has a higher priority than existing wheels, and avoids the need to build blacklists into every project (or doing something else as significant). It also means that users don’t have to choose between using manylinux wheels (and having issues with a small subset of them), and building everything from source, and blocking manylinux wheels.
As an aside to this discussion, I wrote this PEP, and the Disabling Manylinux PEP, because in both cases writing a PEP was viewed as the next step: https://github.com/pypa/packaging/pull/262 for the Disabling Manylinux PEP; https://github.com/pypa/packaging/issues/239 for this one. I’m happy to not write/withdraw this PEP if it’s decided that a PEP isn’t needed, but given PEPs were asked for/desired by project members, it would be good to have clarity about what needs a PEP and what doesn’t in order for patches/PRs to be considered (this isn’t a dig at you Steve, this is me trying to understand how I should be proposing to modify how Python packaging works across projects).