Philipp von Weitershausen wrote:
Jim Fulton wrote:
I've created a proposal to deal with eggifying zope.app:
(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
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
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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list