Baiju M wrote:
>> The packages that we might want to break out (like we did with
>> Acquistion, ExtensionClass, DateTime) should retain their name, so
>> nobody has to change any code to work with them.
> I think we could have added those packages in a namespace.
Why? A million things depend on these with the names they have now.
Inventing a new namespace for the sake of a new namespace and asking all
those applications to change their code is to be obsessive-compulsive.
> What if we want
> to extract similar things out of Zope 2 core. For example DTML related
> things could be extracted out of Zope 2 core.
I doubt there is much stuff there that anyone other than Zope 2 cares
about. Even Acquisition and ExtensionClass are dubious. There's already
a DTML implementation in zope.app somewhere.
> I guess we are planning to improve the WSGI story of Zope 2,
> in addition to creating new packages, we will be required to re-factor
> existing code for this. I hope these kind of "refactoring" would be much
> easier with namespace packages. One of the major contributing factor why
> we were able to create a nice ZTK out of Zope 3 is the use of "namespace".
Mmm... I doubt that. Any module path change is painful. The WSGI story
exists in repoze.zope2 and just needs to be officially blessed if we
want that. I don't see that this has anything to do with re-organising
legacy code that's been there for nearly a decade.
> There are few more important factors:
> - We should not clutter top-level names with Zope 2 specific packages
> This is very important in the context of new distribution mechanism
> we adopted (egg, PyPI). Courtesy to other PyPI users ?
I agree in general, but we are unlikely to have many new packages. Note
that we can name eggs whatever we want, without using namespace
packages. Yes, if someone wanted to use Zope 2's Acquisition in Django
and Django had a module called Acquisition that would clash. If you find
someone who wants to do that, or anything like it, slap them. They'll
thank you later.
> - Branding Zope technologies is also very important. Yes, Zope
> is still a good brand :)
We are doing that with dozens of zope.* packages. If we really are
refactoring things out of Zope 2, they should go into existing/new
zope.* packages. We don't need a new namespace.
> - Some of the things mentioned in this blog by Martin Aspelli:
*cough* *Aspeli* *cough* :)
> PEP 20: "Namespaces are one honking great idea -- let's do more of those!"
They're not such a good idea that we should arbitrarily cause people
pain just to have them. Zope 2 is very old. We have to accept that some
things (like namespace packages or setuptools) just didn't exist when
its architectural decisions were taken.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -