[Distutils] setuptools extras_require

[Phillip J. Eby]

At 09:29 AM 2/9/2007 -0500, Tres Seaver wrote:
> > Using "|" as a separator for ORing TurboGear's requirements might look
> > something like this (ignoring version numbers for simplicity):
> >
> > install_requires = [
> >         "SQLObject | SQLAlchemy",
> >         "Kid | Genshi",
> > ],
> > extras_require = {
> >         "fancy_tb": ["Paste"],
> > }
>
>+1 for the pipe symbol:  to my eye, it means "pick the first of these",
>which is what you want.

It's also implementable; the tuple concept isn't.  Eggs' requirements get 
stored in text files, so there has to be a pure-text representation possible.


> > Setuptools would check if either SQLObject or SQLAlchemy was already
> > installed, if not it'd try from left to right until it successfully
> > installed one of the requirements.

Yeah, it would be pretty straightforward to add the parsing and a new type 
of "Requirement" object to support alternatives, *but* nearly all of 
setuptools expects individual Requirement instances to refer to a single 
project, not multiple alternative projects.  Integrating an alternative 
type of "MultiRequirement" object could introduce random breakage.

Essentially, everything that uses Requirement.parse would need to be 
changed to handle the case where alternative requirements were included, 
and for some parts of setuptools it would be a significant change.  So, 
this is something that'll have to wait for 0.7.

Also, there are some open design questions with this idea.  For example, 
will we need command-line options to allow someone to force installing the 
"best" choices, even if a less-desirable option is still available?  (I 
suppose this could be handled with an extra, e.g. "foo[recommended]".)

And what kinds of installation problems should be considered 
"recoverable"?  Do we want to install a lesser alternative just because a 
server is down at the moment?  Should we in fact ever try to *install* an 
alternative, or merely allow already-installed alternatives to satisfy a 
dependency?

Yet another problem is backtracking.  Right now, the dependency resolving 
algorithm never backtracks.  But in the world of allowing alternatives, it 
seems as though it would need to be able to back out if the first thing is 
installed, but one of *its* dependencies is missing.  Although I suppose 
that could just produce an error... but right now there's no easy_uninstall 
to let you remove the broken item easily.

(These types of questions are why I never implemented this in the first place.)