[Distutils] Choice of dependencies?

Phillip J. Eby pje at telecommunity.com
Tue Dec 6 03:22:26 CET 2005

At 08:45 PM 12/4/2005 +0000, John J Lee wrote:
> > It seems like the straightforward thing to do is treat it as an optional
> > ("extras") dependency, and have the user install matplotlib[Numeric] or
> > matplotlib[numarray] accordingly.
>How about setup.py authors having some means of defining a default
>dependency, where there is an choice of dependencies?

After giving this some thought, it seems to me that there might be a better 
way to conceptualize this.  Instead of "choose 1 of N" dependencies, why 
not allow fallbacks from a requirement?  In other words, if you have the 
preferred package, use that.  If you don't have the preferred package, but 
have the fallback package, use the fallback package.  If you have neither, 
act as though the requirement is the original specified requirement.

This seems like something that I could more likely fit into the current 
architecture, since there are already various fallback stages.  Even so, 
it's not trivial to implement and likely wouldn't be possible before 0.7 or 

>  In my case, and I
>guess for Scipy too (presumably they want people to use scipy_core, all
>else being equal), there's an obvious 'recommended choice'.  That
>recommended choice may vary with time, but ISTM the users often split
>fairly neatly into two groups:
>1. People who just want to say 'give me the standard setup, whatever is
>currently recommended'
>2. People who know just what they want
>It also seems to me that #1 is most often the bigger group.  Those people
>then need to read install instructions specific to the particular package
>they're installing.  It may be that the choice of dependencies isn't
>terribly significant for most users, but they're forced to know about it
>regardless in the current state of affairs.

I'm not sure why; in this particular situation as described it seems to me 
the way to go would be to just require scipy_core, and treat support for 
alternative packages as optional.  That would inconvenience group #2 only 
if they have no intention of ever moving to scipy_core, or if for some 
reason they're unable to build or get it for their platform.

More information about the Distutils-SIG mailing list