Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C.
I know I could (ab)use extras_require, but in my case this is a real dependency rather than an optional extra. The other option I have is to just pick one of the dependencies (B or C in my example above), and thereby force people to install it even though it's not strictly required. Neither option seems particularly attractive.
John
At 08:53 PM 12/3/2005 +0000, John J Lee wrote:
Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C.
Interesting; I'd be curious to know what P, B and C translate to in real packages. :)
I know I could (ab)use extras_require, but in my case this is a real dependency rather than an optional extra. The other option I have is to just pick one of the dependencies (B or C in my example above), and thereby force people to install it even though it's not strictly required. Neither option seems particularly attractive.
I'm surprised that such a condition exists; it seems like one of the two would be redundant.
Phillip J. Eby wrote:
At 08:53 PM 12/3/2005 +0000, John J Lee wrote:
Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C.
Interesting; I'd be curious to know what P, B and C translate to in real packages. :)
P = matplotlib B = Numeric C = numarray D = scipy_core
Until everyone ports their stuff to scipy_core, there are still people who need to use numarray or Numeric to be compatible with other packages.
At 02:09 PM 12/3/2005 -0800, Robert Kern wrote:
Phillip J. Eby wrote:
At 08:53 PM 12/3/2005 +0000, John J Lee wrote:
Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C.
Interesting; I'd be curious to know what P, B and C translate to in real packages. :)
P = matplotlib B = Numeric C = numarray D = scipy_core
Until everyone ports their stuff to scipy_core, there are still people who need to use numarray or Numeric to be compatible with other packages.
Well, there isn't really a way to do 1-of-N dependencies, since you would need a way for the user to pick one to be satisfied by easy_install. 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.
On Sat, 3 Dec 2005, Phillip J. Eby wrote: [...]
Well, there isn't really a way to do 1-of-N dependencies,
OK.
since you would need a way for the user to pick one to be satisfied by easy_install.
That's not a "since", that's an "and" :-)
I know where you're coming from though, of course: no need to explain further.
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? 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.
FWIW, the particular P, B, and C I had in mind are (C is not a current dependency of P, but may or may not an alternative to B be in future):
P: mechanize B: pullparser C: BeautifulSoup
John
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 0.8.
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:
- People who just want to say 'give me the standard setup, whatever is
currently recommended'
- 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.
On Mon, 5 Dec 2005, Phillip J. Eby wrote:
At 08:45 PM 12/4/2005 +0000, John J Lee wrote:
[...]
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
[...]
Makes sense to me.
[...]
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.
Yes, you're right -- I just didn't like requiring something not really required, but I guess it's no big deal for pure-Python packages (which Scipy isn't, of course).
John
participants (3)
-
John J Lee -
Phillip J. Eby -
Robert Kern