Martijn Faassen wrote:
...
Sure, I support dependencies and separating out Zope into sub projects,
I'm just listing an additional use case: the repository state should be
similar to release state, to avoid confusion for developers as well as
people who want to become developers.
I.e. a developer should have the ability to easily see the same (or
similar) code layout, dependencies, etc, as in a release, and someone
familiar with a release should see the same (or similar) code layout,
dependencies, if they become a developer.
Right, got it. A checkout and a release should be very similar.
If eggs work out, then they would both use eggs to satisfy their
dependencies.
Another use case, probably mostly in the context of Five, it's nice to
have an inclusive release of Zope 3 in Zope 2. The goal of reducing the
amount of code included in Zope 2 sounds nice in theory, but it stops
Five developers from exposing Zope 3 code in Zope 2 because it simply
isn't there in a particular release. It is *nice* to have all of Zope 3
included in Zope 2. I don't want to lose that good thing in the rush to
minimize dependencies.
Right now Five/Zope2 include lots of packages they don't and may never
use. I want Five/Zope2 to not *have* to include packages they don't
need just because we've created monoliths. I especially don't want
to release experimental code through Five/Zope2 just because we don't
have our repository and/or packaging in order.
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 )
