Stephan Richter wrote:
On Wednesday 18 January 2006 19:09, Jim Fulton wrote:
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
smaller, but will download needed eggs. This would be a replacement of the
use of externals we have now.
Oh, this will make development so much more tedious. Let's say
zope.testbrowser is an egg and I discover a bug in zope.textbrowser while
doing some other Zope 3 development, I have to check out zope.testbrowser,
fix the bug, check it in, download the new egg and hope it fixed my Zope 3
problem. Honestly this is far too much and I will at most make a bug report.
I beliave that Eggs have a development mode in which you can work on the source.
This apears to be easy to switch too, perhaps easier than editing externals.
I haven't gotten to try this myself. We'll see as we learn more about eggs.
I'm at least as lazy as you are, so rest assured, I'm gonna try to come up
with a methodology that makes my life as easy as possible.
If more than one application uses a package, it is feasible for at most
one application to include it. Managing the application that way makes
it more complicated for other applications to use. For example, the
package's releace cycle becomes bound to the release cycle of the
including application, which is cumbersome for other applications.
I have seen you take a similar approach to zope.testing and I found that
painful just by watching the checkins.
I don't understand what you mean. Having a separate zope.testing project has
been extremely useful. For example, in our comercial apps,
we often used newer versions than existed in Zope 3. We often needed
enhacements to zope.testing at times that Zope 3 was feature frozen.
We could have made a Zope 3 branch just to modify zope.testing, but that
would have been a hassle for us and for Zope 3 developers. Note that
the new test runner (from zope.testing) was used in ZODB long before it
was used in Zope 3.
> I feel like an old record, but please
let's keep the development process as simple as possible. I rather make some
concessions to the packaging and dependency system than spending more time
developing.
Perhaps our goals are different. I want Zope's packages to be usable
outside of Zope. I also want to make it easier to use external packages.
I think that a more package-centric development methodoligy will make
achieving these goals much easier. I also think it will make Zope releases
go smoother because the scope of the release will be narrower. Someday,
A Zope release will include an app-server specific core and a collection of
other package releases. To the extend that those packages have their own
lifeccyles, and quality control, the amount of newly released code in a Zope
release wil be smaller. A package-based approach will also make it easier to
release less. We'll be freed from a "batteries included" mentality that
encourages large high-risk releases. And it will make it easier for people
to make custom releases that have configurations targeted to specific needs.
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
_______________________________________________
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 )
