[Distutils] Dependency extensions

[Phillip J. Eby]

At 06:44 AM 10/17/2007 -0400, Tres Seaver wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Matt Good wrote:
> > On Oct 11, 2007, at 2:20 PM, Tres Seaver wrote:
> >
> >> authors have overspecified dependencies in their requirements for a
> >> given distribution, mostly because they don't want to have to support
> >> their package configurations they don't test.  I'm fine with that line
> >> of thought, as long as I have a way to reuse their packaged stuff in
> >> combination with mine, where I *do* test with a different version than
> >> they do
> >
> > Just because you tested your app against "bar" 1.4 and "baz" 1.3
> > doesn't mean that every feature of "bar" will work with "baz" 1.3.
> > Another app could break because it uses a feature of "bar" that
> > doesn't work with that version of "baz" and the authors of one of
> > those packages will get the bug report about it instead of you.  If
> > you're willing to help with the testing the author might be willing
> > to relax the requirements, but trying to override another package's
> > requirements is likely to lead to problems.
>
>I agree that this might be problematic in a setup where different
>applications share the 'site-packages' directory.  Conflicts of this
>sort drove the development of "virtual_python" / "virtualenv" setups,
>which make it trivial to isolate separate applications' package sets.

Then perhaps such overrides should be used mainly for virtual 
environments, where you can prioritize *whose* requirements should 
take precedence.  That is, if you are installing 'foo' into a 
virtualenv intended only for the running of 'foo', then it might be 
reasonable for its requirements to take precedence.

However, ISTM that the "right" solution (for some value of "right") 
is that packagers who wish to overspecify their dependencies should 
create virtual packages for that purpose, rather than baking 
fixed-version requirements into the base package.