Re: [Zope-dev] multiple packages in the same namespace
On Fri, 6 Feb 2009 12:24:14 -0500 Jim Fulton j...@zope.com wrote: On Feb 6, 2009, at 7:35 AM, Chris Withers wrote: Jim Fulton wrote: zope.configuration isn't a namespace package. It is simply a package with subpackages. Does setuptools support something like: packagea: packagea/__init__.py packagea/amodule.py packagea.something: packagea/__init__.py packagea/something/__init__.py packagea/something/bmodule.py No. According to the setuptools documentation and our experiments on the sprint, this is supposed to work and does work: When you declare a package to be a namespace package, it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages. If so, which packagea/__init__.py gets used? Only the __init__.py isn't allowed to have code is what I read from the documentation. That's why it doesn't. :) That's also why zope.configuration isn't a namespace package. I'm not arguing to turn it into a namespace package, I just wanted to point out the technical issues are different. Christian -- Christian Theune · c...@gocept.com gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 6 OK, 4 Failed
Summary of messages to the zope-tests list. Period Fri Feb 6 12:00:00 2009 UTC to Sat Feb 7 12:00:00 2009 UTC. There were 10 messages: 10 from Zope Tests. Test failures - Subject: FAILED (failures=6) : Zope-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:19:46 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011041.html Subject: FAILED (failures=7) : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Fri Feb 6 21:21:19 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011042.html Subject: FAILED (failures=6) : Zope[2.buildout]-trunk-alltests Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:26:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011045.html Subject: FAILED (failures=7) : Zope[2.buildout]-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Fri Feb 6 21:27:33 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011046.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Fri Feb 6 21:13:43 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011037.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:15:14 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011038.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:16:46 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011039.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:18:16 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011040.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Fri Feb 6 21:22:49 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011043.html Subject: OK : Zope[2.buildout]-trunk Python-2.5.4 : Linux From: Zope Tests Date: Fri Feb 6 21:24:33 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011044.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] ZCML implementations: where should they go
Hi there, We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have. Right now ZCML directives are implemented in packages that contain other implementation. For example, zope.component implements various ZCML directives, and zope.security implements some more. In the case of zope.component, a special [zcml] extras dependency section is declared. If the ZCML dependencies are asked for, using zope.component will suddenly pull in a much larger list of dependencies than the original zope.component dependency list. The ZCML directives are component-related, but do offer extra options that need bits from the wider Zope 3 framework, such as the security infrastructure. In the case of zope.security, this isn't the case. As far as I can see, it doesn't declare any dependency beyond zope.configuration to allow it to implement its ZCML directives. The dependency situation for the ZCML implementations in zope.component doesn't appear ideal. It was therefore proposed to move the ZCML implementations to another package. This could be a new package, or it could be created. Following up on that, it was considered we should move *all* directives from the packages that implement them now into special packages. This would allow some packages to lose the dependency on zope.configuration, which is a relatively minor gain. We have several ways to go: a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here. c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security. I personally don't like extras. I think the ideal situation would be if packages had *no* extras at all (even test extras), as it complicates reasoning about the dependency structure. I think with improved structuring of the dependency graph, a package should have enough in its implementation dependencies to implement its tests. We've already experienced some of that last week at the sprint. For ZCML, with improved structuring of the dependency graph a package should only need zope.configuration as an extra package to implement ZCML. For that reason, a) is not really an option for me. That leaves b) and c). I think for now we should go with c), as it's the smallest step forward that will help clean up things. That is, we either find and appropriate package that makes sense for the ZCML implementations in zope.component, or we create a new package. Of course if we create a new package we still have a naming discussion ahead and I risk sparking another naming discussion (as it's easy to have an opinion about names). So, what do people think about option c)? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Martijn Faassen wrote: We've recently had some discussions on where to place the implementation of various ZCML directives. This post is to try to summarize the issue and analyze the options we have. Thanks for summarizing this! We have several ways to go: a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. -1 from me. I see the test extra as a necessary evil to get us moving with the lessened-dependency project. Multiple extras will just cause an increasing number of combinations of packages which aren't tested anymore. If you have a extra in your package, it should be possible to move the added functionality from the extra into a package that depends on the original package. b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here. c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security. +0 Seems reasonable to me. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hey Hanno, Thanks for your feedback! Hanno Schlichting wrote: Martijn Faassen wrote: [snip] a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. -1 from me. [snip motivation I agree with] options b and c: +0 Seems reasonable to me. Anything you'd actually be +1 on? :) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCML implementations: where should they go
Hi Martijn, Without comparison otherwise, you may find my thoughts here useful: http://www.martinaspeli.net/articles/granting-plone-an-api a) continue with the current extra dependencies situation like in zope.component, and in fact clean up other packages that define ZCML to declare ZCML extra dependencies. -0.5 I think this will require more discipline than usual, and it'll a pain to test how a package behaves both with and without extras. b) pull out all ZCML implementations from where they are now and put them in special ZCML implementation packages. We could for instance have zcml.component, or zope.component_zcml, or zope.configuration.component. We had a bit of a side-tracked discussion about naming and namespace packages here. +0.5 I would suggest we have a namespace package and a naming convention to allow this to grow over time. For example, we could have a zope.zcml.* naming convention, so you'd have zope.zcml.component, zope.zcml.content and so on. Having a single package could become painful when people start refactoring and branching, as you could easily get into situations where it becomes hard to upgrade or manage releases. c) pull out only those ZCML implementations that cause extra dependencies beyond zope.configuration. So, we extract the bits of zope.component into a new package, but we don't extract bits from zope.security. -0.5 This policy sounds confusing to me, which means that people will probably screw it up. :) For that reason, a) is not really an option for me. That leaves b) and c). I think for now we should go with c), as it's the smallest step forward that will help clean up things. That is, we either find and appropriate package that makes sense for the ZCML implementations in zope.component, or we create a new package. Of course if we create a new package we still have a naming discussion ahead and I risk sparking another naming discussion (as it's easy to have an opinion about names). So, what do people think about option c)? I see no problem with starting with zope.component, but I'd consider both naming conventions and package structure conventions in a wider context before making the leap with zope.component, to reduce the chance of inconsistencies in the future. Martin -- 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 http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
