[Zope3-dev] Zope 3 a la carte

[Martijn Faassen]

Fred Drake wrote:
> On Fri, 08 Oct 2004 00:40:45 +0200, Martijn Faassen <faassen at infrae.com> wrote:
> 
>>I've done a small experiment with zpkg today, but it looks like far more
>>packages get included than I'd hoped for.
>  
> Lovely, isn't it?
> 

Yeah, glorious. :)

>>It seems many packages in Zope 3 don't state their dependencies. Is the
>>intent to add this and nobody has gotten around to do this, or is there
>>some other reason behind this? 
> 
> What do you think is missing?  Note that the dependencies are stated
> for each packaging component, not per Python package.  This is
> particularly evil for zope.app.

I don't understand this. What is a packaging component? If dependencies 
were there for each Python package, it would be easier for *me* to 
decide what I want to package, right? I mean, your packaging component 
might not be mine. I for instance want parts of zope.app for Five, but 
most of it I can ignore.

>>There are also issues like Five using zope.app.container, say, but only
>>to import events and not actually any of the rest of the implementation.
>>In some cases I suspect that for Five to be functional actually less
>>dependencies would be needed than a particular package needs to fully
>>function.
>>
>>Many packages are likely pulling in stuff from the ZODB for instance,
>>but a Five-subset of Zope 3 wouldn't need the ZODB at all, as Zope 2
>>already has one. :)
>  
> There's dependency, and then there's packaging.  Something that
> depends on ZODB packages should state them.
> 

Typically dependency information does drive packaging, right? You'd just 
sometimes like to make some exceptions.

>>There are some strategies to cope with this, I imagine:
>>
>>* in case of the ZODB one, we'd need a way to say 'well, these are the
>>dependencies, but for Five, this is actually not a dependency'. Perhaps
>>a 'global dependency exclude list' is an option.
>  
> Yes.  Some way to tell zpkg not to actually include particular
> dependecies would help a lot.  I'm aware of this, but haven't had time
> to deal with this (since I didn't need it for Zope X3).
> 

Okay, good to know you're aware of it, thanks!

>>* refactor various packages, moving stuff out of zope.app into zope. Or
>>at least, splitting stuff up into parts, where some part need less
>>dependencies than others.
>  
> This is going to be painful, and I suspect won't yield much for it
> most of the time.  It really depends on how many different aspects of
> a problem are dealt with by any one module, and I don't know that we
> have all that many truely evil offenders here.  But I could be wrong
> about that.  ;-)

It's true that this is the painful option, but I'm just listing it among 
possibilities. It may make sense for some packages, though I think being 
able to say "this is not something you should include even though it's a 
dependency" would already fix much of the problem. Not all of it I think 
though -- sometimes you want to import something from a package, and 
it's completely standalone, but the package's __init__.py imports 
something you don't want to depend on at all. This would probably be a 
refactoring candidate.

>>* ignore the dependency mechanism in zpkg entirely and only package up
>>those packages explicitly listed. This is already possible, I believe? 
> 
> It's possible to not use the dependency mechanism with packaging, but
> then you get a distribution for exactly one package (whatever you name
> on the command line).  It's not possible (or very reasonable) to
> change this at this point.  The exclusions list makes a lot of sense
> though.

Okay, so I'm holding out for the exclusions. It's not very urgent for 
Five as it's easy enough to point people to ZopeX3, but it's not without 
interest either. When Silva starts to depend on Five, I would like a 
better story than "Oh, you need to install all of Zope X3 as well".

Regards,

Martijn