Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ? Well, I don't have any name suggestion :) Regards, Baiju M
On Tue, Dec 29, 2009 at 6:40 PM, Baiju M <mbaiju@zeomega.com> wrote:
Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ?
One more example: "plone.app."" Regards, Baiju M
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Baiju M wrote:
On Tue, Dec 29, 2009 at 6:40 PM, Baiju M <mbaiju@zeomega.com> wrote:
Hi, I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ?
One more example: "plone.app.""
No, it would not be useful. The BBB damage would be catastrophic. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAks6cd8ACgkQ+gerLs4ltQ5iyACgt/OdKbAjkNBvE1j6tsbm6l/h jIwAoMvLXFChEowqReyklV6XwOO9pJDi =m8B7 -----END PGP SIGNATURE-----
On Tue, Dec 29, 2009 at 2:10 PM, Baiju M <mbaiju@zeomega.com> wrote:
I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ?
What would be the advantage of that? It'd break every single existing import. Most of those packages aren't reusable in the wild and shouldn't be released outside of the Zope2 distribution. 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. Hanno
On Tue, Dec 29, 2009 at 6:51 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Dec 29, 2009 at 2:10 PM, Baiju M <mbaiju@zeomega.com> wrote:
I was going through Zope 2 source code today. There are 20+ top-level packages specific to Zope 2. Would it be useful if we move those packages to a top-level namespace package. I mean something similar to: "zope.app.*", "grokcore.*", "repoze.bfg.*" ?
What would be the advantage of that? It'd break every single existing import. Most of those packages aren't reusable in the wild and shouldn't be released outside of the Zope2 distribution.
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. 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 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". 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 ? - Branding Zope technologies is also very important. Yes, Zope is still a good brand :) - Some of the things mentioned in this blog by Martin Aspelli: http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-... PEP 20: "Namespaces are one honking great idea -- let's do more of those!" Regards, Baiju M
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* :)
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and-...
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. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
participants (4)
-
Baiju M -
Hanno Schlichting -
Martin Aspeli -
Tres Seaver