Re: [Zope-dev] multiple packages in the same namespace
Christian Theune wrote at 2009-2-7 09:36 +0100: ... 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. However, extreme care must be taken to avoid name clashes. For Modules/packages with the same name it is not deterministic which of them will actually be loaded. __init__.py is just a common case of this problem. -- Dieter ___ 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
Previously Martijn Faassen wrote: 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 I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE. 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 It solves the problem in a consistent way 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.1 This introduces inconsistencies that might be confusing. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Tests results for Zope 3.5dev KGS
For now I only have the py2.5-64bit slave, but I have similar results, though less tests: http://zope3.afpy.org/buildbot/ 12895 tests, 27 failures, 10 errors I'll add other slaves soon (32bit and py2.6). Christophe Stephan Richter a écrit : Hi all, I just ran all tests over night and here is the result Tests with errors: runTest (zope.testing.testrunner.runner.SetUpLayerFailure) runTest (zope.testing.testrunner.runner.SetUpLayerFailure) runTest (zope.testing.testrunner.runner.SetUpLayerFailure) runTest (zope.testing.testrunner.runner.SetUpLayerFailure) runTest (zope.testing.testrunner.runner.SetUpLayerFailure) runTest (zope.testing.testrunner.runner.SetUpLayerFailure) testDoomedTransaction (zope.app.publication.tests.test_zopepublication.ZopePublicationTests) testTransactionAnnotation (zope.app.publication.tests.test_zopepublication.ZopePublicationTests) testTransactionCommitAfterCall (zope.app.publication.tests.test_zopepublication.ZopePublicationTests) testAbortTransactionWithErrorReportingUtility (zope.app.publication.tests.test_zopepublication.ZopePublicationErrorHandling) Tests with failures: /opt/zope/packages/eggs/ZODB3-3.9.0a10-py2.5-linux-i686.egg/ZEO/tests/zeo_blob_cache.test /opt/zope/packages/eggs/z3c.etestbrowser-1.2.1-py2.5.egg/z3c/etestbrowser/README.txt /opt/zope/packages/eggs/z3c.layer.minimal-1.0.1-py2.5.egg/z3c/layer/minimal/tests/../README.txt /opt/zope/packages/eggs/zope.app.testing-3.6.0-py2.5.egg/zope/app/testing/cookieTestOne.txt /opt/zope/packages/eggs/zope.app.testing-3.6.0-py2.5.egg/zope/app/testing/cookieTestTwo.txt /opt/zope/packages/eggs/zope.file-0.4.0-py2.5.egg/zope/file/contenttype.txt /opt/zope/packages/eggs/zope.file-0.4.0-py2.5.egg/zope/file/download.txt /opt/zope/packages/eggs/zope.file-0.4.0-py2.5.egg/zope/file/upload.txt /opt/zope/packages/eggs/zope.html-1.1.0-py2.5.egg/zope/html/browser.txt /opt/zope/packages/eggs/z3c.form-1.9.0-py2.5.egg/z3c/form/tests/../form.txt /opt/zope/packages/eggs/z3c.form-1.9.0-py2.5.egg/z3c/form/tests/../group.txt /opt/zope/packages/eggs/z3c.formjs-0.4.1-py2.5.egg/z3c/formjs/tests/../jsclientevent.txt /opt/zope/packages/eggs/zc.catalog-1.3.0-py2.5.egg/zc/catalog/extentcatalog.txt /opt/zope/packages/eggs/zc.catalog-1.3.0-py2.5.egg/zc/catalog/extentcatalog.txt normalize (zc.i18n.date) /opt/zope/packages/eggs/zc.table-0.7.0-py2.5.egg/zc/table/column.txt /opt/zope/packages/eggs/zc.table-0.7.0-py2.5.egg/zc/table/fieldcolumn.txt test_ctl (zc.zope3recipes.tests) test_sane_errors_from_recipe (zc.zope3recipes.tests) work_with_old_zc_deployment (zc.zope3recipes.tests) /opt/zope/packages/eggs/zc.zope3recipes-0.7.0-py2.5.egg/zc/zope3recipes/README.txt test_provides (zope.app.interface.tests.test_interface.PersistentInterfaceTest) test_error_handling (zope.formlib.tests) /opt/zope/packages/eggs/zope.schema-3.5.1-py2.5.egg/zope/schema/tests/../validation.txt /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/setupstack.txt /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/testrunner/testrunner-debugging-layer-setup.test /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/testrunner/testrunner-layers-ntd.txt /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/testrunner/testrunner-layers.txt /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/testrunner/testrunner-profiling.txt /opt/zope/packages/eggs/zope.testing-3.7.1-py2.5.egg/zope/testing/testrunner/testrunner-profiling-cprofiler.txt Total: 12937 tests, 30 failures, 10 errors in 41 minutes 1.150 seconds. Regards, Stephan ___ 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] Planning for Zope 3.5
Am Sonntag 01 Februar 2009 07:51:43 schrieb Stephan Richter: Hi all, now that we have Zope 3.4.0 finally behind us, let's look forward. As I said in the release notes, I am really willing to switch to a 6 months release cycle again. I think there are three areas that we can work on: - Python 2.6 support. - Dependency reduction. - Improve project setup Yes, I'd also suggest this. What I'd also like to have is: - More focus on z3c.form/z3c.pagelet and less on the ZMI. - More focus on SQLAlchemy integration. And something I wonder from time to time is if it would be possible to integrate a recent Twisted release into Zope3, or, even better, directly use the current twisted egg with Zope3. Best Regards, Hermann -- herm...@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 ___ 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] Planning for Zope 3.5
2009/2/8 Hermann Himmelbauer du...@qwer.tk: And something I wonder from time to time is if it would be possible to integrate a recent Twisted release into Zope3, or, even better, directly use the current twisted egg with Zope3. The problem is that the Twisted egg doesn't contain the web2 module, used by zope's twisted-based WSGI server, so we can only try to integrate the latest release into zope.app.twisted itself, downloading the Twisted release using svn:external as we do now. I tried do do that before, but tests failed and I was unable to fix that, as I don't know twisted at all (shame on me). -- WBR, Dan Korostelev ___ 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
2009/2/8 Dieter Maurer die...@handshake.de: Each individual extra :extra is equivalent to a separate package _extra depending on (and potentially many other things). The extras are just a convenient way to avoid cluttering the distribution namespace. That said, I like a). +1 -- WBR, Dan Korostelev ___ 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] Tests results for Zope 3.5dev KGS
2009/2/8 Christophe Combelles cc...@free.fr: For now I only have the py2.5-64bit slave, but I have similar results, though less tests: http://zope3.afpy.org/buildbot/ 12895 tests, 27 failures, 10 errors I'll add other slaves soon (32bit and py2.6). Great! BTW, can you please set the english locale for buildbots? :) -- WBR, Dan Korostelev ___ 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 Sat Feb 7 12:00:00 2009 UTC to Sun Feb 8 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: Sat Feb 7 21:10:33 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011051.html Subject: FAILED (failures=7) : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sat Feb 7 21:12:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011052.html Subject: FAILED (failures=6) : Zope[2.buildout]-trunk-alltests Python-2.4.5 : Linux From: Zope Tests Date: Sat Feb 7 21:16:35 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011055.html Subject: FAILED (failures=7) : Zope[2.buildout]-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Sat Feb 7 21:18:05 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011056.html Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.7 : Linux From: Zope Tests Date: Sat Feb 7 21:04:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011047.html Subject: OK : Zope-2.9 Python-2.4.5 : Linux From: Zope Tests Date: Sat Feb 7 21:06:02 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011048.html Subject: OK : Zope-2.10 Python-2.4.5 : Linux From: Zope Tests Date: Sat Feb 7 21:07:32 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011049.html Subject: OK : Zope-2.11 Python-2.4.5 : Linux From: Zope Tests Date: Sat Feb 7 21:09:02 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011050.html Subject: OK : Zope[2.buildout]-trunk Python-2.4.5 : Linux From: Zope Tests Date: Sat Feb 7 21:13:33 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011053.html Subject: OK : Zope[2.buildout]-trunk Python-2.5.4 : Linux From: Zope Tests Date: Sat Feb 7 21:15:03 EST 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-February/011054.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] Merge zc.copy with zope.copypastemove and zope.location.
The README.txt of zc.copy says that the components, provided by this package is apropriate for inclusion in Zope itself. The package provides a more pluggable mechanism for copying generic persistent objects (not only ILocation's) as well as a way to register post-copy hooks to be executed, which is very useful, for example when dealing with persistent objects that have non-ZODB bits (like filesystem based files related and so on). However, the package is really small and mostly contains modified copies of zope.copypastemove's ObjectCopier and zope.location's locationCopy. So, I propose to merge the zc.copy package's changes with original zope.copypastemove/zope.location and deprecate it. If noone objects, I'll do that myself. -- WBR, Dan Korostelev ___ 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
Wichert Akkerman wrote: I'ld rather not see a whole slew of extra packagse appear. I also wonder how the extra number of packages and increasing size of sys.path influence performance and restrictions on environments like GAE. For environments like GAE you don't want setuptools and its magic to be part of your application. This is were repackaging your entire app into one zipped egg or some other flat structure comes in handy. Setuptools and eggs are a distribution format from my point of view. They are certainly not the best way to deploy your applications. The growing sys.path is affecting performance to some degree in all deployment environments. 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
Martijn Faassen wrote: 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? :) I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever. Grok has different needs for the configuration part of your application. repoze.bfg takes yet another approach. Once we define a Grok-like API for Plone we will probably end up with yet some other kind of different semantics. My gut feeling is that the best long term answer would be to figure out how to split zope.configuration and ZCML kind of in the middle. What parts of application configuration are actually reusable and which are not. How does application configuration and system configuration like paste.ini and zope.conf fir together? Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer. 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] Merge zc.copy with zope.copypastemove and zope.location.
After looking at the whole copy thing for some more time, I thought that it even makes sense to extract the object cloning functionality to some zope.copy (or even zope.persistentcopy) package that will contain clone and copy functions as well as ICopyHook mechanism, but won't contain IObjectCopier implementation, because the clone and copy functions from zc.copy are useful without any container context. Then zope.copypastemove and zope.location could just depend on the zope.copy, so we won't introduce many dependencies for zope.location and make people able to easily copy persistent objects w/o installing on zope.copypastemove or even zope.location. 2009/2/8 Dan Korostelev nad...@gmail.com: The README.txt of zc.copy says that the components, provided by this package is apropriate for inclusion in Zope itself. The package provides a more pluggable mechanism for copying generic persistent objects (not only ILocation's) as well as a way to register post-copy hooks to be executed, which is very useful, for example when dealing with persistent objects that have non-ZODB bits (like filesystem based files related and so on). However, the package is really small and mostly contains modified copies of zope.copypastemove's ObjectCopier and zope.location's locationCopy. So, I propose to merge the zc.copy package's changes with original zope.copypastemove/zope.location and deprecate it. If noone objects, I'll do that myself. -- WBR, Dan Korostelev -- WBR, Dan Korostelev ___ 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] Merge zc.copy with zope.copypastemove and zope.location.
Okay. I prepared the zope.copy package in the SVN for you to check out what I mean. :) 2009/2/8 Dan Korostelev nad...@gmail.com: After looking at the whole copy thing for some more time, I thought that it even makes sense to extract the object cloning functionality to some zope.copy (or even zope.persistentcopy) package that will contain clone and copy functions as well as ICopyHook mechanism, but won't contain IObjectCopier implementation, because the clone and copy functions from zc.copy are useful without any container context. Then zope.copypastemove and zope.location could just depend on the zope.copy, so we won't introduce many dependencies for zope.location and make people able to easily copy persistent objects w/o installing on zope.copypastemove or even zope.location. 2009/2/8 Dan Korostelev nad...@gmail.com: The README.txt of zc.copy says that the components, provided by this package is apropriate for inclusion in Zope itself. The package provides a more pluggable mechanism for copying generic persistent objects (not only ILocation's) as well as a way to register post-copy hooks to be executed, which is very useful, for example when dealing with persistent objects that have non-ZODB bits (like filesystem based files related and so on). However, the package is really small and mostly contains modified copies of zope.copypastemove's ObjectCopier and zope.location's locationCopy. So, I propose to merge the zc.copy package's changes with original zope.copypastemove/zope.location and deprecate it. If noone objects, I'll do that myself. -- WBR, Dan Korostelev -- WBR, Dan Korostelev -- WBR, Dan Korostelev ___ 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] Retiring the Zope SVN trunk!
Andreas Jung wrote: On 03.02.2009 13:56 Uhr, Hanno Schlichting wrote: It becomes somewhat hard and annoying to keep the old full Zope trunk tree based on externals in sync with the Zope2 buildout and its KGS definition and it seems I failed yesterday. I'd suggest we reorganize the Zope trunk and replace it by the current buildout. As part of that we can move the code that has been moved to its own projects like Acquisition and DateTime out of the main tree. I'd volunteer to do this work if nobody objects. I had time to work on this on our Berlinale Sprint and this is now done! I marked the old Zope2.buildout area as retired after moving the code, so we don't confuse people anymore with two locations doing the same. 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
On Feb 7, 2009, at 11:07 AM, Martijn Faassen wrote: 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. I did this in zope.component out of desperation. (I was preparing to teach a PyCon tutorial on using zope.component outside of Zope.) I'm not at all happy with it, however, I'd be in favor of continuing it for existing packages with zcml implementations so as not to introduce backward incompatibilities. I'd rather not do it for new packages. IMO, introducing an extra is like introducing a new package and in a rather complicated way. 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. I think this is the right way to go for new software. 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. Too complicated imo. :) 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. +1 ... For that reason, a) is not really an option for me. As I said above, I'm for a) because I think it is less disruptive, even though I share your distaste for extras. Jim -- Jim Fulton Zope Corporation ___ 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
Martin Aspeli wrote: [snip] 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. We already had a rather fruitless naming discussion, which is why I'm still in favor of option c) (avoiding the creation of new packages where possible). Option b) risks us creating a lot more small packages that we'll have to manage, and ultimately I'd like to *reduce* the amount of packages in the Zope framework. And as I already said, I like small steps. I think we should adhere to the principle that a package should have the code and dependencies to run its tests, with typically no test extras needed therefore, and no dependencies just to support testing. I think we should also have the principle that code to configure a concepts introduced by a package (such as component configuration, security configuration) should be in that package, if at least this doesn't expand dependency requirements. I saw that this principle seemed to work fairly well when we moved ZCML directives out of both zope.app.security and zope.app.component into zope.security: these directives were mostly (though not entirely) about security anyway, and the move didn't introduce new dependencies. 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: Hanno Schlichting wrote: [snip] Anything you'd actually be +1 on? :) I haven't figured out yet, what I'd like to do with ZCML and zope.configuration in general. It seems to me that ZCML is right now too tightly bound to application configuration. Zope2 and Five need different action handlers and this will continue to be the case for the next years and possibly forever. I thought significant process was made on the ability to reuse more handlers now that Zope 2 has got __parent__ support. Not enough? Some progress has been made. But some of the actions actually do have a different semantic in Five, like all the resource things. The URL scheme they produce is different for example. Some others will need to adhere to different security needs or use different base classes for the automagically inserted classes. Last time I looked there was no clear next step that would need to be taken to remove more custom handlers. Just trying to push out ZCML in itself seems better than having it stay in, but not what I'd consider to be a good long term answer. I'd consider it at least a necessary step towards a long term answer, so you should be +1 for step one. :) I'm +0, since I don't yet know, where the journey will take us and if this is a step into the right direction. If others drive this forward, I'm fine with it. I'm just not going to put lots of my time into it just yet. 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] Merge zc.copy with zope.copypastemove and zope.location.
As the author, +1 and thank you! Gary On Feb 8, 2009, at 11:18 AM, Dan Korostelev wrote: Okay. I prepared the zope.copy package in the SVN for you to check out what I mean. :) 2009/2/8 Dan Korostelev nad...@gmail.com: After looking at the whole copy thing for some more time, I thought that it even makes sense to extract the object cloning functionality to some zope.copy (or even zope.persistentcopy) package that will contain clone and copy functions as well as ICopyHook mechanism, but won't contain IObjectCopier implementation, because the clone and copy functions from zc.copy are useful without any container context. Then zope.copypastemove and zope.location could just depend on the zope.copy, so we won't introduce many dependencies for zope.location and make people able to easily copy persistent objects w/o installing on zope.copypastemove or even zope.location. 2009/2/8 Dan Korostelev nad...@gmail.com: The README.txt of zc.copy says that the components, provided by this package is apropriate for inclusion in Zope itself. The package provides a more pluggable mechanism for copying generic persistent objects (not only ILocation's) as well as a way to register post-copy hooks to be executed, which is very useful, for example when dealing with persistent objects that have non-ZODB bits (like filesystem based files related and so on). However, the package is really small and mostly contains modified copies of zope.copypastemove's ObjectCopier and zope.location's locationCopy. So, I propose to merge the zc.copy package's changes with original zope.copypastemove/zope.location and deprecate it. If noone objects, I'll do that myself. -- WBR, Dan Korostelev -- WBR, Dan Korostelev -- WBR, Dan Korostelev ___ 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 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] Merge zc.copy with zope.copypastemove and zope.location.
On Feb 8, 2009, at 5:18 PM, Dan Korostelev wrote: 2009/2/9 Gary Poster gary.pos...@gmail.com: As the author, +1 and thank you! Glad to hear. I'll release the result of the merge soon. BTW, I'd also like to make a final release of zc.copy, replacing its code with dependencies/imports from newer zope.copy and zope.copypastemove. You mean 1.1. OK. If I were doing it, I would make 1.1b - 1.1, and then make a 1.2 that was as you described. If you don't agree or feel like it that's fine. Can you please add me to package owners on PyPI (my name there is nadako). Done. Also, should I use deprecated deferred imports or plain imports for that? I'm generally not a fan of the deprecated imports. I'd say just put it in the docs. Again, if you disagree, I don't feel too strongly about it. Gary ___ 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.location.pickling.PathPersistent
Hi there. While refactoring zope.location to use the new zope.copy package, I came on PathPersistent class in the zope.location.pickling module. It does quite the same as old CopyPersistent, but based on object location paths instead of ids. I can't find any code that actually uses that class and I don't think that it makes much sense. So I'd propose to just remove it. What do you people think? Also, Martijn, Christian, was it the only reason for moving ITraverser interface from zope.traversing to zope.location? If so, can we still move it back? -- WBR, Dan Korostelev ___ 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] Tests results for Zope 3.5dev KGS
On Sunday 08 February 2009, Christophe Combelles wrote: For now I only have the py2.5-64bit slave, but I have similar results, though less tests: http://zope3.afpy.org/buildbot/ 12895 tests, 27 failures, 10 errors I'll add other slaves soon (32bit and py2.6). Fantastic! That's great news. BTW, I think you can take Py3.0 from the list, since we are not aiming at supporting it yet. I think several problems are shallow: - Restricted Python fails for strange reasons. Installing the trunk as devel egg works. I think it has something to do with Sidnei making the latest release and he is on Windows. - The z3c.form issues should be fixed in trunk. Anyone, how close are we to a z3c.form 2.0 release? (Mmmh, I guess I should know. ;-( Adam? Roger? Dan? Malthe?) - Several other packages fail because they have not been adjusted to the latest refactorings. Those are the low-hanging fruits I think. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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] Tests results for Zope 3.5dev KGS
2009/2/9 Stephan Richter srich...@cosmos.phy.tufts.edu: Anyone, how close are we to a z3c.form 2.0 release? I worked on the multi widget a little some time ago, adding conditional add/remove buttons. However, there are still some (not too important though) TODOs on it. Also, there's a really strage bug with macros when using z3c.pt discovered in tests/simple_groupedit.pt. I leaved a comment there [1], I guess that's for Malthe. :-) I think, I'll try to make a review of current z3c.form's state and write more on that. [1] http://svn.zope.org/z3c.form/trunk/src/z3c/form/tests/simple_groupedit.pt?view=auto -- WBR, Dan Korostelev ___ 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] [Checkins] SVN: z3c.layer/tags/0.3.0/setup.py -dev
Am 08.02.2009 um 05:14 schrieb Stephan Richter: On Saturday 07 February 2009, Michael Howitz wrote: Changed: U z3c.layer/tags/0.3.0/setup.py I'll note that we retired this package in favor of z3c.layer.minimal z3c.layer.trusted etc. Thanks for clarification. After releasing z3c.layer I noticed the other packages. So I'll do another release pointing to the split-of packages and delete the trunk of z3c.layer so it is clear that the package is dead. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · 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 )
Re: [Zope-dev] Tests results for Zope 3.5dev KGS
2009/2/9 Dan Korostelev nad...@gmail.com: 2009/2/9 Stephan Richter srich...@cosmos.phy.tufts.edu: Anyone, how close are we to a z3c.form 2.0 release? I worked on the multi widget a little some time ago, adding conditional add/remove buttons. However, there are still some (not too important though) TODOs on it. Also, there's a really strage bug with macros when using z3c.pt discovered in tests/simple_groupedit.pt. I leaved a comment there [1], I guess that's for Malthe. :-) I think, I'll try to make a review of current z3c.form's state and write more on that. [1] http://svn.zope.org/z3c.form/trunk/src/z3c/form/tests/simple_groupedit.pt?view=auto Oh, also, I guess it should use z3c.ptcompat rather than z3c.pt.compat for z3c.pt thing. -- WBR, Dan Korostelev ___ 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 )
