Gary Poster wrote:
[snip a few things that we think would be nice and useful for the packages]
Sure. I'd love to. I'm happy if I at least get the stuff open-
sourced, though. Life is full of compromises.
I understand the spirit in which these were donated to the community,
and it's appreciated. Note that I'm in the same state with the 'hurry'
package; it's also sitting off in an svn repository somewhere without a
I just wanted to start talking about the next step to make the status of
these packages more clear. Stephan and I have been talking, and he has a
lot of ideas about how to start managing this, so I'll wait for his
proposal and comment on that.
[snip questions on how to install these packages]
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 concerned about those developers, or system administrators later on,
who unlike you and me, do not have the patience to figure it out for
themselves. I'm not cool with whatever myself, as I will need to explain
it to others and I'd prefer a single obvious way to do it in that case.
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
We don't have a policy, we have intelligence guided by experience,
since we've never done anything like this before.
Okay, so then we're free to make up a policy for the future. :)
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.
That'll make it a bit more consistent, which is good. I saw that the new
zc packages appear to all have a 'src' directory which contains the code
itself - that's a good consistency. We can put README.txt, dependency
information and setup.py and the like in the outer package eventually.
Zope3-dev mailing list