Proposal - expanding optional dependencies to support opt-out of recommended/default installables

Packaging
1

what if the +/- signs could be used to define extras that install by default or get a opt-out

for example

[project]
name = "fun"
[project.optional_dependencies]
"+cli" = [ "rich" ]

then asking for fun should imply fun[cli] but asking for fun[-cli] would opt out of the auto-add

it could also be spelled as

[project]
name = "fun"
[project.recommended_dependencies]
"cli" = [ "rich" ]
4 Likes
2

i was made aware of a prior proposal

that would possibly best integrate with a new recommended dependencies key for pep621 style spelling

3

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.

6 Likes
4

i started a initial draft at WIP: initial base draft for default extras by RonnyPfannschmidt · Pull Request #1 · RonnyPfannschmidt/python-peps · GitHub

it will need some refinement before getting it reviewed in a wider cycle

2 Likes
5

A couple of issues I want to point out for the proposal:

  1. 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.
  2. 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.

1 Like
6

Will pip not warn if installing a wheel with a higher metadata version than the highest version it supports?

7

Yes, it wiil.

1 Like
8

I think they were asking if pip will warn when installing a wheel with a higher Core Metadata version than it supports, not wheel version.

1 Like
9

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.

2 Likes
10

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.

1 Like