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:[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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to