Just for reference, there have been several other prior proposals to solve a similar problem that have attracted significant discussion, with the most extensive and developed (besides the one you mention above) being this one:
ISTM that there is a lot of interest from users and no major show-stopping objections, but the main blocker has just been there are a lot of tricky details, behaviors and specific interactions to work out, and thus far the discussion hasn’t gotten enough of a critical-mass consensus on these issues to motivate someone to write and propose at least a pre-PEP, which would be the presumed next step.
A couple of issues I want to point out for the proposal:
This changes the behaviour of a “bare” package name in the specifier significantly—pip install foo will install different things depending on what version of pip the user has. Since it is virtually impossible for a package author to ensure users properly read documentation before installing the package, this issue would likely cause enough confusion for authors to not use the feature for a very long while.
Both the bare dash and dash-leading names were valid extras prior to PEP 685, which pip still has not fully implemented. They are unlikely to be used very widely (no obvious sematic meaning), but would still require a deprecation period after PEP 685 implementation. And the behavioural change may cause yet more confusion to slow down adoptation.
Instead of the default/recommended extra approach, I am personally more in favour of the “negative extra” approach, i.e. specifying an extra (or something similar but not an extra) to remove default dependencies. This would keep the behaviour of a bare-name install unchanged, and support for this would be more clearly indicated since the new syntax would emit an error on older installers.
I did a quick search and pip does not seem to warn about newer metadata versions (of Core Metadata i.e. value in METADATA, not wheel metadata i.e. WHEEL-METADATA). This should be fixed. But even if it does this, a metadata version warning is much too vague IMO. Also IMO changing the behaviour of the bare package name install is bracking backward compatibility and should bump the major metadata version, which should make pip fail according to the specification (it doesn’t right now—again, should be fixed) and wouldn’t help adoption.
Generally speaking we’ve broken strict backwards compatibility without bumping the major version. I don’t think strict adherence to semver helps much of anyone here.
It’s a balancing act with how widespread we think the breakage is likely to be.
Also note, that it wouldn’t be the first time where we changed the behavior of a “bare” package name in the specifier which would change based on what version of pip they are installing with. For instance, the support for python-requires, the support for yanking, the support for wheels all together, every time we add support for a new type of wheel, etc.
Like any feature we add, it does typically mean that maintainers have to wait awhile before they can rely on it’s existence. This isn’t unique to this feature, and exists for pretty much every feature we add targeted towards package maintainers. A quick skim of the rough draft seems like it’s pretty easy for maintainers to not rely on it, since users on older versions of pip can still manually select the extras they want, but get a better experience for people who upgrade their pip.
That being said, I’ve only quickly skimmed the draft, so I don’t have particularly strong opinions one way or the other, I just wanted to point out that those objects don’t feel like they are strong reasons not to do something if we ultimately think it is a good idea.