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

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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to