[Distutils] Idea: Positive/negative extras in general and as replacement for features

Ronny Pfannschmidt opensource at ronnypfannschmidt.de
Tue Dec 15 13:54:49 EST 2015

Hello everyone,

the talk about the sqlalchemy feature extra got me thinking

what if i could specify extras that where installed by default, but
users could opt out

a concrete example i have in mind is the default set of pytest plugins
i would like to be able to externalize legacy support details of pytest
without needing people to suddenly depend on pytest[recommended] instead
of pytest to have what they know function as is

instead i would like to be able to do something like a dependency on
pytest[-nose,-unittest,-cache] to subtract the items

the extras declaration in setup.py would just include a * sign at the

an elaborate concrete example could be

extras = {
 +cache: pytest-cache
 +lastfailed: pyytest[+cache], pytest-lastfailed
 +looponfail: pytest[+lastfailed], pytest-looponfail
 +unittest: pytest-unittest
 +nose: pytest[+unittest], pytest-nose

also a dependency declaration using the + sign in the extras should not
imply the default extras of the package, while usage of the - should

so depending on pytest[+unittest] would only imply the unittest support
but depending on pytest[-nose] would include all positive extras except
for nose
please note in particular the dependencies on other postive extras,
those are put in,
so a negative for unittest can imply that nose can't be sensibly used as

if +nose did instead depend directly on pytest-unittest, then excluding
it would be a unreasonably tricky resolving algorithm with potential for
lots of mistakes
instead spelling the direct dependency on positives/negatives can
resolve inside of a package and still leave room for more outside of it

this is in particular relevant if a package with extras is depended on
twice in different packages,
because in that case each of the dependence's requirements should add up
to the combined set

there is also room for fleshing out algorithms for interacting the
positive/negative dependence sets,
but i'll leave that for later

as an addition to that later on there could be support for partial wheel
wheels, so features could be materealiyed as wheel package with a
special name
and build tools could fall back to making them from a sdist

as a example, there would be a sqlalchemy package as source wheel,
a sqlalchemy*cext package as windows wheels, and pip would have to find
a source distribution to compile the wheel package

-- Ronny

More information about the Distutils-SIG mailing list