On Thu, Mar 3, 2016 at 8:30 PM, Ronny Pfannschmidt <i...@ronnypfannschmidt.de> wrote: > > > 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
I only just saw this thread because Ronny's recent(-ish) reply, and I agree with him. In my mind the use case for something like this is pretty independent of "more complex" interactions like Robert's example. I think the idea here is that if I run `pip install pytest[-unittest]` I'm not saying the `pytest[-unittest]` must never ever be installed on the system. Rather, it's useful in a far more limited cases where I need more fine-grained control over what's installed--think for example application bundles or running on embedded systems. A case that would be useful to me would be to have an `astropy[tests]` extra that is installed by default. The astropy test suite is a bit weighty, especially due to the size of test files. I've proposed making the tests an extra before but that was shot down (I think rightfully) since it would be preferable to have it installed by default. However, for cases where the tests take up too much space a `pip install astropy[-tests]` would be nice--there's not likely to be an additional package that depends on `astropy[tests]` and even if there were I'd know in building my system whether or not I really need it. The alternative is post-install stripping down of packages, which can be unpredictable and error-prone in my experience. Erik _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
