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

[Martijn Faassen]

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).

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

collective.namedfile - modified so that it allows some 
subclassing/configuration that allows..

collective.namedblobfile (or whatever the name is) - subclassing/using 
collective.namedfile functionality but also needs blob support, so pulls 
  in extra dependencies

megrok.form - uses collective.namedblobfile

Optionally the last two can be folded in one package.

If the easiest way to make this work is to modify collective.namedfile, 
and modifying megrok.form directly results in a mess, then you'd think 
that this approach should work too. Instead of in a single Python 
package you'd have code in two, but that isn't a very fundamental 
difference.

Regards,

Martijn