(apologies to Martijn and Stephan for repeating this email: zope.org rejected my previous emails)

On Feb 6, 2006, at 6:51 AM, Martijn Faassen wrote:

Stephan Richter wrote:

On Monday 06 February 2006 06:13, Martijn Faassen wrote:

Is this stuff intended to end up in the zope core eventually? If so,
what steps will need to be taken? I imagine this also ties into the eggs
story, but the question on the zope core perhaps still stands - what
would be a dependency of the zope core?

In light of the recent discussion at the Plone Snowsprint, there is a general desire to have a common repository for Zope 3 addons that are useful, but might not be appropriate for the core. In my opinion we would like to be able to control the license and quality of this repository. Basically, it should be core-quality/ ready code in an add-on place. Thus, it would also require those packages to follow the Zope 3 development process. I have had positive feedback about this idea from the Plone developers.

Also important is regular releases for these packages.

Sure. I'd love to. I'm happy if I at least get the stuff open- sourced, though. Life is full of compromises.

Released versions do:

* publicity

* make it clear for which zope version my add-on package release is going to work. Right now it's unclear whether the add-ons are for Zope 3.2, or Zope 3 trunk, or what.

FWIW, for this particular example, most of the new ZC ones are developed on trunk, and several of them are also tested on 3.2. No way to know that looking at 'em, I know.

Additionally, we should make it easy for people to install these packages in a canonical way. Right now, this is confusing... I had some things to say about general package layout here:


With a package in the 'zope' namespace, what am I supposed to do when I install it? Symlink it into lib/python of my Zope 3 software home?

When I have two separate packages in the zc namespace, how am I supposed to install that?

I can get it all working of course, but it's non-obvious and there are multiple ways to do it. There should a single obvious way to do it.

Sure, if you like. I'm cool with whatever, as long as it doesn't add too much ceremony to actually open-sourcing our code.

For those watching at home, one obvious alternative for UNIX-based systems is symlinks; less obvious but cross-platform alternative is using pkgutil.extend_path from the standard library.

I'm also worried about putting non-core packages into the namespace 'zope'. It's unclear what ZC's policy is in this; some packages are in the 'zope' namespace, other packages are in 'zc'. And not only ZC is adding things to the 'zope' namespace; there's zope.paste, for instance.

We don't have a policy, we have intelligence guided by experience, since we've never done anything like this before.

Note that Jim wants to make the zope package in the repository smaller, and divide up the zope namespace into separate projects that can be knit together. We don't know how this will work yet, which is what conversations like yours will hopefully suss out.

FWIW, right now generally the "zope" namespace for us includes things that we (a) know from the beginning that we want to open-source, and (b) are fundamental, things that in the past we would have just added to the repo because we would have been confident that "the world" wanted them as part of Zope.

Maybe we'll do "zc" packages exclusively from now on.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to