(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:
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.
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
story, but the question on the zope core perhaps still stands - what
would be a dependency of the zope core?
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:
* 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
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
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,
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