Hi Martijn, On Tuesday 24 April 2007 00:30:47 Martijn Faassen wrote: > Michael Kerrin wrote: > [snip] > [snip] > > 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 favourite option. > > 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. :) Thanks, Michael _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com