Am 09.02.2016 um 22:24 schrieb Robert Collins:
Sorry for not replying for so long.
On 16 December 2015 at 07:54, Ronny Pfannschmidt
<opensou...@ronnypfannschmidt.de> wrote:
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
So the challenge here will be defining good, useful, and predictable
behaviour when the dependency graph is non-trivial.
Using your example, what should pip do when told
pip install pytest[nose, -unittest] proj2
and proj2 depends on pytest[unittest]
?
those should be additive,
negative extras should be used purely to leave out dependencies for a
single requirement
if something else needs them, then they should of course be included
even a dependency on pytest itself should include the unittest dependency
negative requirements should be absolutely local and only effect the
dependency graph of a single direct dependency
so if there is another dependency without that negation, then it should
consider the full graph in any case
If it installs pytest[unittest], then the first pytest dependency was
no honoured. If it does not install pytest[unittest], then the proj2
dependencies were not honoured. So it must error.
-> Which means that using a [-THING] clause anywhere is going to be
super fragile, as indeed 'never install with X' things are in
distributions - its much better to find ways to express things purely
additively IMO.
There are many more complex interactions possible with the + / - DSL
you've sketched - and I don't think they are reducible - that is, its
not the DSL per se, but the basic feature of allowing cuts in the
graph traversal that lead to that complexity. If we can come up with
good, consistent, predictable answers, even considering three-party
interactions, then I've no objection per se: but I think that will be
very hard to do. I certainly don't have time at the moment to help -
sorry :(.
-Rob
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
