Philipp von Weitershausen wrote:
Jim Fulton wrote:
I've created a proposal to deal with eggifying

(That's a confusing title for a proposal that deals with eggifying, because it seems to me that the configuration issue is just a minor detail in the overall process of making an egg(s))

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


We wish to distribute the Python packages now contained in the package in separate eggs. This would probably consist of a large 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

I agree somewhat. One of the benefits of the "" 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 anymore doesn't mean we shouldn't try to make some of the 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 that is expressed by PACKAGE.cfg and by the ZCML files in
I'm happy to see these whittled down further., 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 (, 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 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 more finely, Go for it.

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

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

- How to treat as a namespace package without breaking existing

It is not my goal in the proposal to decide precisely how to factor the 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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to