[Grok-dev] Re: collective.namedfile + blob

[Christian Theune]

Hi,

On Fri, Mar 14, 2008 at 11:24:00AM +0100, Martijn Faassen wrote:
> Ethan Jucovy wrote:
>> On Thu, Mar 13, 2008 at 6:51 PM, Martijn Faassen 
>> <faassen at startifact.com 
> [snip]
>>      >  I've also created a branch of collective.namedfile (but doesn't
>>      >  commited yet) with the same additions, but I don't like the idea of
>>      >  adding ZODB 3.8 as a dependency of it. There is any way to add a
>>      >  "conditional dependency" in setup.py? It would be great if we can
>>      >  install collective.namedfile without z3c.blobfile / ZODB 3.8
>>     dependecy
>>      >  in Plone and install *with* these dependecies on Grok / Z3.
>>
>>     I don't know of a good way to do this.
>>
>>
>> Could you achieve this with `extras_require`?  I don't think it's 
>> really much like the intended purpose but it might work;
>>
>> {{{
>> setup(name="collective.namedfile",
>>  ...
>>  extras_require = {"z3grok": ["z3c.blobfile", "ZODB==3.8"]},
>> )
>> }}}
>>
>> And then I think you would `easy_install collective.namedfile[z3grok]`  
>> (or include "collective.namedfile[z3grok]" in another setup.py's  
>> install_requires) to have those conditional dependencies pulled in.
>
> I've only heard bad things about extras_require, unfortunately. I tried  
> to google up the reasons Jim Fulton gives for disliking extras_require,  
> but unfortunately I'm not able to find them. With buildout they are used  
> for optional test dependencies (as tests_require is unfortunately  
> useless as it doesn't store any real package data). I think it would be  
> very hard to make all of this work right, as I don't know of a way to  
> know *how* you are installing a package (now I want the blob support, so  
> gimme those extras too).

Jim's argument (IIRC) is that you can't test them properly. If you write a
library that has N extras and that in turn depends on a library that has M
extras. You would have to run your tests in all the (N+1)*(M+1) possible
combinations. If people use lots of extras this can become messy and
unpredictable very early.

The use of the `test extra` has a similar problem: as you test with different
dependencies than when you use the package, how do you know that your package
will actually work in the different environment -- you never tested it. (Also
called: test what you fly, fly what you test.)

I'm still using extras for the tests though to keep the actual dependencies
for the consumers of my library packages down, but I think really hard before
putting a package in there.

> I really think the best way to deal with this is to split the  
> responsibilities:

This is an approach that would work as it spells out all those elements out of
the (N+1)*(M+1) mess that will be tested and are explicitly supported. No
implicit recombination of features possible though. :/

Christian

-- 
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development