On Tuesday 24 April 2007 00:30:47 Martijn Faassen wrote:
> Michael Kerrin wrote:
> You can almost do this, but now quite, as z3c.webdav is not a namespace
> package in this plan (see below).
> > An other two options I can think of, instead of the naming convention
> > above:
> > 1. create a webdav namespace, webdaz (WebDAv for Zope), which would
> > contain webdaz.core, webdaz.zopefile, webdaz.zopelocking etc
> It's nice that it's more flat. I think it's too easy to mistype 'webdaz'
> for 'webdav', so -1 on this one from me. zwebdav would in fact have my
> preference if you want to go this way.
Either name works for me so lets go for `zwebdav`.
> > 2. Name the core webdav implementation z3c.webdav and then create eggs
> > that are named like zope.file.webdav (for zope.file),
> > zope.app.file.webdav, z3c.extfile.webdav, zope.locking.webdav etc. but
> > which are separate from the underlying module.
> This won't work, as these packages themselves are not a namespace
> package. As far as I'm aware, you can only create independently
> installable eggs for subpackages of namespace packages (i.e. packages
> without any code).
Thanks, you just saved me from wasting a lot of time as this was original my
> > Does any one have any experience with this type of problem or does any
> > one of a preference to which one they like best. Or is there other
> > options that I have missed that is worth considering, in order for me to
> > move this forward.
> Another option is to create a zwebdav or z3c.webdav package, and then
> put a special namespace package in there meant for the extensions:
> zwebdav - core zope 3 webdav support
> zwebdav.ext - pure namespace package
> zwebdav.ext.zopefile, zwebdav.ext.zopelocking, etc.
> ToscaWidgets is an example of a package that does this. It has a
> toscawidgets core, and then extensions are shipped as subpackages of the
> toscawidgets.widgets namespace package.
> Yet another option would be to have a core package, and then extension
> package in another namespace altogether:
> zwebdav - core webdav support
> zwebdavext.zopelocking, zwebdavext.zopefile - extensions
This I like, but renaming zwebdavext -> zwebdavapp :-) This allows a clearer
seperatation between the protocol components and the application components,
which is what want now that I think about it.
For example zwebdavext.zopefile isn't really an extension but more integration
code for zwebdav and any application which uses zope.file. Then in the future
I can hopefully get to work on zwebdav.dasl, zwebdav.acl etc. which are
extensions to the protocol and hence should belong in zwebdav with more
coresponding integration modules in zwebdavapp.
> Grok does this. It has 'grok' as the core, and extensions are shipped as
> 'megrok.five' and so on.
> Incidentally, we are thinking about splitting up grok into multiple
> packages too. A difference with what you're talking about is that the
> grok package will remain the same, but will start importing some of what
> it needs from other packages which can be used independently.
> For that, we intend to do something like this:
> grok - package end users see, and depends on
> groklib (name still being pondered) - core grokker implementation
> grokcore.component - basic component architecture support for grok
> grokcore.formlib - formlib support for grok
> etc. The grokcore packages would have dependencies on groklib as well as
> various Zope 3 packages (such as zope.component). Some of them may also
> build on each other. groklib wouldn't have any dependencies (or almost
> none). grok would depend on everything. Not very relevant to your
> problem, but thought I'd show yet another example of package
> organization. :)
Zope3-dev mailing list