[Zope3-dev] Re: RFC: Loading Configuration from the zope.app Egg

[Jim Fulton]

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
>> I've created a proposal to deal with eggifying zope.app:
>>
>>   http://zope3.zwiki.org/LoadingConfigurationFromTheZopeAppEgg
> 
> (That's a confusing title for a proposal that deals with eggifying 
> zope.app, because it seems to me that the configuration issue is just a 
> minor detail in the overall process of making zope.app an egg(s))

I don't agree. Making something an egg is generaly pretty straightforward.
The proposal focuses on the specific challenges for zope.app, which
is the fact that it is almost a namespace package.

...

>> We wish to distribute the Python packages now contained in the 
>> zope.app package in separate eggs. This would probably consist of a 
>> large zope.app egg containing the packages listed in the current 
>> PACKAGE.cfg file and a number of other eggs for other commonly used 
>> but optional packages in zope.app.
> 
> I agree somewhat. One of the benefits of the "moving-out-of-zope.app" 
> process was that we looked at each package's dependencies and removed a 
> bunch of interdependencies that were unnecessary. Now that we're not 
> moving stuff out of zope.app anymore doesn't mean we shouldn't try to 
> make some of the zope.app packages independently usable. 

Perhaps.  To me, it is very important that 3.4 be egg based.  In fact,
I want to get to an egg-based checkout much sooner than that.  For
that reason, I'd like to limit the scope as much as possible.  I also
want to reduce risk.  Right now we have a working definition of
zope.app that is expressed by PACKAGE.cfg and by the ZCML files in zope.app.
I'm happy to see these whittled down further.

> zope.app.container, for example, deserves its own egg and so do a bunch 
> of other packages.

I'm not convinced, but I won't argue the point.  If you think you can whittle
things further, then go for it.

> Basically, the goal of my original proposal 
> (http://zope3.zwiki.org/MakeZopeAppSmaller), that Zope 2 should be able 
> to use core Zope 3 functionality without having to include the Zoep 3 
> application server, is still valid, IMO.

I agree. I wonder which packages in PACKAGE.cfg you don't need in Zope 2.

> I'd rather see many zope.app 
> eggs with well-defined dependencies than one big chunk with a few 
> additional eggs.

That's fine with me.

> I think your proposal should be amended with some specifics regarding 
> which eggs we will see in the future.

No, that's outside the scope of my proposal.  I think it is fine if you
want to factor zope.app more finely, Go for it.

My proposal is targeted at a very narrow but blocking issues. namely:

- Whether to treat zope.app as a namespace package, so that we
   can avoid moving things, and

- How to treat zope.app as a namespace package without breaking existing
   configurations.

It is not my goal in the proposal to decide precisely how to factor the
zope.app egg itself.  I mentioned a possible factoring, using the word
"probably".  I'll note that the factoring is outside the scope of my proposal.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org