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

[Ronny Pfannschmidt]

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
> <opensource at 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
>
>
>
>