Jim Fulton wrote:
Martijn Faassen wrote:
How do you assemble releases 'from releases'? I'm not sure I
understand that. You mean make a Zope 2 release using a Zope 3 release?
No, I mean using eggs. Zope should be broken into separate projects
with their own eggs. A Zope release might just be an egg with
Or it might just be a collection of eggs.
Ah, makes sense. A 'meta-package', so to speak. Works well in Debian, so
I think that's an interesting pattern to follow. As long as we can do
those micro releases quickly -- the problem is that Zope 3 is one
project, and we want one communication channel, as we simply don't have
enough people otherwise. From another perspective it's many projects,
You know my position concerning the repository and the release; I'd
prefer them to be kept as similar as possible to simplify the release
process. I hope we can go in that direction. It also makes things more
predictable to developers. We noticed that some Zope 3 packages
weren't packaged into Zope 2 after the release, even though in a
developer's sandbox of Zope 2 they were there.
Right. If eggs work out, then a respository check out will be a lot
but will download needed eggs. This would be a replacement of the
use of externals we have now.
A risk here is that if I find a bug in package X, I can't easily track
it into package Y and fix it there, as package Y is an egg. The current
system doesn't have this problem.
As a side issue: From the perspective of Five, it is beneficial to
have as much Zope 3 code included into Zope 2 releases, as that gives
us an opportunity to start using this functionality right away,
exposing it to Zope 2, without waiting for a new release.
Understand though that there is nothing like a backward compatibility
promise for something that hasn't been released.
Yes, but Zope 2 included *less* than Zope 3 in the most recent release,
and I'd like *all* packages that are in a Zope 3 release to be available
in a Zope 2 release. I.e. Five doesn't want packages that aren't in a
Zope 3 release, but not less either.
(If you're interested I can try to explain some of my thinking a bit
deeply.) Eggs are a nice distribution mechanism, but I'd also want the
knitting process to work for a SVN checkout -- developers working with
SVN need to be very easily work with a 'knitted' version, so perhaps
svn:externals will remain a valuable tool.
Assuming that eggs fullfill their promise, I think I'd
rather use eggs than externals.
Sure, but see the risk I mentioned earlier in this mail.
As part of this decomposition, we need to make zope.app much smaller.
Early in Zope 3 development, I proposed a simple rule for
organization of the repository: Anything that depended on zope.app
went in zope.app. Anything else went in zope. If there was doubt,
put it in zope.app. I think that served us well at the time, but I
think we've moved beyond that, I'd like to migrate most of zope.app
elsewhere. Zope 2.10 should not include zope.app.
This worries me; Five is currently using massive quantities of code in
zope.app, and as expressed above, I value Five having access to
potentially all Zope 3 code that's in a Zope 3 release.
The code that Five is using will still be available, but it will be
somewhere else (with necessary backward compatibility hacks).
As long as Zope 2.10 contains all packages in Zope 3.
Zope3-dev mailing list