Philipp von Weitershausen wrote:
<snip />
I don't think all of these things should go into the Products.Five
anymore, for several reasons:
* We're trying to get away from writing products and into writing Python
packages that can e.g. be installed as eggs.
* Some of these things are not essential to bringing Zope 3 technology
into Zope 2 (e.g. like the intid stuff), so it may be questionable
whether it should ship with Zope 2/Five out of the box.
* Starting with Zope 2.10, Products.Five is actually getting smaller
which is a trend I would like to continue to see. And if I manage to
land my Acquisition refactoring in 2.11, Products.Five will pretty soon
decrease in size tremendously, and there are also other things in
Products.Five that should really be in Zope 2 proper (e.g. OFS).
+1 to this logic
Proposal
--------
So, what I'm proposing is to feature-freeze the Products.Five package
and just basically keep making it work for future Zope versions. Five
1.6 (current trunk) will work for Zope 2.11 (current trunk), Five 1.7
for 2.12, etc. So, essentially there won't be Five feature releases in
between anymore, which means we can put Products.Five into the
Zope/lib/python/Products proper.
New stuff will be added in standard Python packages that may or may not
ship with Zope 2, Plone or whoever needs them. I personally almost don't
care, it's really only about defining the right egg dependencies in
Plone 3.0 or Zope 2.11, I would assume (see also 'Risks' below). This
seems like the release manager's job who would include stuff based on
requests from the community and package maintainer's recommendations.
The namespace for these packages should probably be 'five', as we
already have five.intid and five.customerize and we are, after all, the
Five project.
+1
Advantages
----------
* We'll be able to use stuff we get for Python packages for free, such
as installation via eggs, Cheeseshop presence and much less majyck for
initialization.
* Stuff that we create as part of the Five project does not necessarily
have to end up in Zope 2. Currently, stuff added to Products.Five
eventually always ends up in some Zope 2 release which means we'll have
to maintain it forever, no matter how crappy it turns out to be (e.g.
Products.Five.site).
flipped around, it would be nice to see the crufty features in Five
moved out to their own packages, to enable BBB *if needed*. this is
similar to nuxeo's XYZonFive product pattern, but easy_install-able.
* Development of certain components can move much faster than even Five.
New things like five.intid or five.customerize can be experimented with
and already be in the right place if they turn out to be stable. If not,
they won't harm Products.Five, either. Individual packages rather than
one big one also reduces the amount of work that has to be done by the
Five release manager (IOW my work ;)).
would like to note that other packages in Zope2 also need this ability
to release asynchronously from Zope2's schedule; ZopeTestCase in
particular comes to mind(Testing should be a namespace package imho).
Risks
-----
* If five.* packages need ZCML config (and I know some will), they will
either have to be included the Zope 3 way (site.zcml or package-includes
slug in your instance's 'etc' directory), or we need to come up with an
approach that Zope 2 people are more comfortable with. I think an egg
entry point would be a compelling solution.
big +1 here. would love to use paste deploy to configure my zope instance.
There are plans to do this
in Zope 3 even so that you can provide configuration from Python instead
of ZCML. I expect this to land in Zope 3.4 which means we should be able
to take advantage of it in 2.11.
I will defer to other's here but say this: I'd rather have better tools
to configure with than more options in the configuration language.
* It is unclear to me at this point what Zope 2's egg story will be. I
*hope* that 2.11 will get the same egg story as the Zope 3.4 that ships
with it does, though noone has talked about eggifying Zope 2 yet. We
should probably do that.
re zope2 egg story:
some talk has occurred thanks to goldegg and general irritation suffered
by myself, rocky, nouri and others. Tres and McDonc have definitely
plumbed the ugly depths of zope2 thinking about this problem for
goldegg. Nouri has run the plone stack as an egg; I've run Zope2 as an
egg.
re my experience, I made a somewhat indecipherable post about my
experiences with easy_install-ing zope from svn with workingenv.
To reiterate, the results are pretty cool: all of zope is installed into
your workingenv/lib/python, all your scripts(repozo, mkinstance, etc)
are installed into your workingenv/bin . Some minor edits are required
to make the scripts find the proper libs(due to SOFTWARE_HOME path
expectations) and the site skeleton disappear but really, it's darn
close to working as an egg.
workingenv takes care of the nasty "where should my zope stuff go in
relation to the real python world" question. it's likely that you could
use setup_tools prefixing to run multiple different versions of zope in
the same env; or just simply make a 2.10 env for your 2.10 instance.
this means that the "egg story" really doesn't have to happen inside
zope(except for wort removal on the Zope2 package). It can just use a
well thought out existing python egg story: workingenv(see
http://bfhammer.blogspot.com/2006/09/bootstrapenvironment.html for more
info).
Perhaps if we want to spruce it up a bit, zopectl could handle
workingenv's "source bin/activate" and maybe alias the command "install"
to the workingenv's easy_install from the zopectl prompt. The
distribution could just be a small setup script for zopectl w/ a
workingenv recipe that sets up the equivalent of the software home.
We still have to handle the Products issue for add ons(mcdonc, donde
estamos con Basketos?). But if Basket is added to 2.11, this might not
be such a big deal.
this probably more of a separate proposal on "what should the Zope2 egg
story be?" so if you have feeling, reply as such.
-w
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
