Re: [Zope-dev] Porting zope.dottedname to Python 3
Hello, * Marius Gedminas mar...@gedmin.as [2013-02-05 17:56]: The mailing list archive contains a lot of advice. (If this were a wiki page, I'd add links to the relevant emails). What I'm trying to do here is to provide a concrete example of the porting pattern discovered by others (especially Lennart Regebro and Tres Seaver): Thanks for the thorough writeup! Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WebSockets API
Hi, * Alex Leach albl...@york.ac.uk [2012-11-25 20:00]: I was wondering if anyone has implemented a WebSockets server API using the zope toolkit? I've just submitted a blueprint on Launchpad (https://blueprints.launchpad.net/zopetoolkit-project/+spec/websockets-api), but thought it might be quicker and easier to discuss how one could do this here. I'm not too familiar with WebSocket internals, but one thing that stuck with me is that you'll need to keep *lots* of open connections, which is only feasible with an eventloop-based server (which zope.server, for one, isn't). Apart from that, I'm not sure what features remain, and where a proper home in the ZTK world would be. At our company we've scheduled a project to integrate WebSockets into a large Zope3-based application for early next year, so we'll definitely will be doing *something* in that space -- we just don't know what, yet. ;) What functionality did you have in mind that the ZTK might grow? Wolfgang -- Wolfgang Schnerring · w...@gocept.com · Software development gocept gmbh co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · Tel +49 345 219401-0 Python, Pyramid, Plone, Zope · consulting, development, hosting, operations ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to change how code ownership works.
* Lennart Regebro rege...@gmail.com [2012-08-19 13:01]: On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl j...@dataflake.org wrote: Legally, both are disallowed unless there's some proof (written statement etc) from the code author that he assigns ownership of the patch or the contents of that pull request to the contributor who is doing the checkin. This is then, IMO a problem that we should fix. What you are in fact saying is that the current system are violating people's copyright everytime we merge a non-contributors patch. It is unfeasible to not merge peoples patches, and I think it is also a big problem that the way the ownership of the code works now inhibits the increased simplicity of making and merging fixes for non-core contributors. In other words, we have had an ownership situation which is terrible, and nobody seems to have realized this until now. Well, now we know. As such, the discussion must now shift from don't do this to how do we do this. Poeple want to contribute and we should not say don't do that, we have to figure out *how* to make it possible to do that, and pretty pronto as well. Yes, please, let us try and shift the discussion from stop it right there! to how can we make this work?. I think this means taking seriously both sides of the story, a) Using Github is found to be quite attractive by lots of people. b) We need to be diligent in maintaining the chain of custody of code so the copyright situation is kept clean. As far as I understand it, the legal lynchpin is that using Github (strongly) encourages merging code contributions of people that did not sign a contributor agreement -- which is the same situation as if someone attaches a patch file to a bug tracker ticket, but will be much more frequent and likely to happen. Could we, then, adopt a policy that we only merge pull requests (or whathaveyou) from people that have signed a contributor agreement? a) Tres, Jens: Would that work from a legal perspective? b) Ross, Alex: Would that still yield the advantages of the distributed source control model? What other solutions would be possible? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: release persistent as a standalone package
* Tres Seaver tsea...@palladion.com [2012-06-30 20:02]: I have completed the work needed to make 'persistent' distributable as a standalone package. The effort (begun almost four years ago!) includes the following highlights: I would like to release a '4.0.0' version of the package, and switch the ZODB trunk to pull it in as a dependency (deleting the currently included (older) copy of persistent). +1, please do. This seems like a(nother! :) Good Thing(tm) to me. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: proposing to merge 'tseaver-test_cleanup' branch of zope.component to trunk
* Tres Seaver tsea...@palladion.com [2012-06-28 00:04]: I've done with the porting / test cleanup effort on this branch: svn+ssh://svn.zope.org/repos/main/zope.component/tseaver-test_cleanup Highlights of the changes in this branch, targeting a 4.0 release: - Added PyPy and Python 3.2 support (tested by tox): - 100% unit test coverage. Unless there are strong objections, I plan to merge this to the trunk this week, and make a 4.0.0 release. +1 please do -- those are lots of steps in the right direction, thanks for tackling this! Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge proposal: zope.interface/branches/tseaver-no_2to3
* Tres Seaver tsea...@palladion.com [2012-04-05 22:36]: Having merged the 'tseaver-better_unittests' branch to the zope.interface trunk last Friday, I now have a new branch ready for merging: http://svn.zope.org/zope.interface/branches/tseaver-no_2to3 The branch excises the use of the 'lib2to3' module and associated fixers in favor of a compatible subset which supports Python 2.6, 2.7, 3.2, and PyPy 1.8. At this point all tests pass under all four environments using 'python setup.py test' as well as using 'nosetests.' Code coverage is at 99.9% (two edge-case lines are untested). Woot! However alluring the 2to3 idea might have been, it seems to me that the single-source approach (with the six package if needed) is the only sane way to go. Unless the community's consensus is against the branch, I plan to merge it to the zope.interface trunk by early next week. +1, please do! Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: z3c.form/trunk/setup.py Get ready for 2.6.1 release.
* David Glick davidgl...@groundwire.org [2012-02-19 22:56]:
On 2/16/12 11:55 PM, Adam GROSZER wrote:
So you say that if I add
entry_points={
'zest.releaser.releaser.after_checkout': [
'zest_pocompile = zest.pocompile.compile:compile_in_tag',
],
},
to z3c.form's setup.py fullrelease will take care of the po files?
You'll have to experiment -- the suggestion was based on what I've heard, not
personal experience with zest.releaser.
The entrypoint looks sound at first glance, but what I'm wondering (and
rather doubting, in fact) is whether zest.releaser includes the package
it currently is releasing to its PYTHONPATH. But yeah, as David said,
you'll probably need to fiddle around with this a little.
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.server still used?
* Chris McDonough chr...@plope.com [2011-12-18 03:57]: Is zope.server still largely used by e.g. bluebream, grok, and other zope 3 apps? Or do people tend to use other WSGI servers instead? We're using zope.server on several Zope 3 projects (that were begun before grok or WSGI or anythin existed ;), and it's *ahem* serving us just fine, no hiccups, no nothing, just doing its job. (We, too, see the occasional broken pipe error in our logs like Marius mentioned, I think that's due to requests that were aborted client-side, thus more an annoyance than anything.) On the other hand, we still haven't found a WSGI server we're happy with for deployment (as opposed to development). Paster has been known to randomly die on us (yup, I've only got anecdotes and nothing hard and fast, sorry), and the whole area of daemon management, logging, logrotation and so forth (not to mention buildout integration) seems not as advanced as we've come to know. What do people use here, what are your experiences and ideas? Wolfgang -- Wolfgang Schnerring · email/jabber: w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Announcement: gocept.zcapatch 1.0 released
* Stephan Richter stephan.rich...@gmail.com [2011-12-05 09:16]: On Monday, December 05, 2011 12:43:35 PM Wolfgang Schnerring wrote: So we decided to solve our most immediate needs (that are not taken care of by plone.testing's stacking solution of the global registry), namely temporarily altering utility/adapter/handler registrations. Why did you not just wrap the config in a z3c.basegeistry directive? I'm afraid I don't understand how that could help in what I'd like to do. The use case I'm concerned with looks roughly like this: def test_client_code_that_uses_IFoo_utility_correctly(self): fake_utility = mock.Mock() fake_utility.underlying_method.return_value = 'canned response' self.zca.patch_utility(fake_utility, IFoo) client_code.perform() fake_utility.underlying_method.assert_called_with(correct_arguments) With the additional conditions that - I'm probably loading configure.zcml in the layer of this test, which defines real IFoo (and, possibly, IBar) utilities. - The client code under test might (or might not) use IBar; either way, I don't care, and certainly don't want to have to mock it, too, for *this* test. - Other tests will likewise want the real IFoo implementation. In other words, I want to replace the utility precisely for this test, isolated from all other tests, and isolated from the layer setup below. plone.testing's stacking approach might help, but only as long as only zope.component.getGlobalSiteManager() is concerned, and as long as I'm only adding or exchanging stuff (come to think of it, I should go and check whether I can remove things registered in __bases__ by registering None in the stacked registry...). As far as I can tell, z3c.baseregistry merely introduces another registry (with __bases__ set up sensibly), so I don't think that can help here, or can it? Wolfgang -- Wolfgang Schnerring · email/jabber: w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Announcement: gocept.zcapatch 1.0 released
Hello, after much discussion[1], Thomas Lotze and I tried to implement generic copying/stacking of component registries[2], but ultimately failed due to the same issues that Martin Aspeli had already foreseen: For the general case there are way too many edge cases, especially regarding persistent registries. So we decided to solve our most immediate needs (that are not taken care of by plone.testing's stacking solution of the global registry), namely temporarily altering utility/adapter/handler registrations. We've now released this effort as gocept.zcapatch[3], and look forward to comments and further ideas about this. I also wonder whether this might eventually get another home (plone.testing? zope.component? Or, nowadays, zope.interface?), but that's for after trying it out in the real world. Wolfgang [1] http://thread.gmane.org/gmane.comp.web.zope.devel/26469/focus=26484 [2] http://svn.zope.org/zope.component/branches/wosc-test-stacking/ http://svn.zope.org/zope.interface/branches/wosc-test-stacking/ [3] http://pypi.python.org/pypi/gocept.zcapatch -- Wolfgang Schnerring · email/jabber: w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] merge zope.configuration dictactions branch
* Chris McDonough chr...@plope.com [2011-12-05 04:02]: ssh://svn.zope.org/repos/main/zope.configuration/branches/chrism-dictactions I want to be able to associate a new value (introspectables) with each ZCML configuration action On the zope.configuration trunk (and in all past releases), each ZCML action is maintained as a tuple. The tuple can be of any length up to seven elements, but mustn't exceed a length of seven. the z.config code is much easier to understand when the action is just a dictionary instead of a pseudo-struct. +1, this makes a lot of sense to me. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Supporting interworking with repository branches on github
* Tres Seaver tsea...@palladion.com [2011-11-22 22:46]: On 11/22/2011 12:13 PM, Laurence Rowe wrote: While the Zope Foundation deliberates on version control, I think it's likely that development will continue using Git and Github. Please don't try to jump the gun on the process here [...] It is not appropriate for a small subset of the community to preempt this kind of choid: ask forgiveness rather than permission is *not* going to fly here, and trying to push harder only irritates folks you might otherwise persuade. When reading the emails on this list about this topic, I get a strong feeling of us vs. them. Is that really necessary? In that light, and trying to make visible the (positive!) aspects of the different opinions, allow me to ask: Tres, while I realize that you also rightly raise the formal issue that a vocal minority shouldn't surge ahead and create facts, do I understand you correctly that the main inherent[1] issue is a legal one, concerning proper handling of copyright etc.? Could someone explain what's at stake here, since at least I only have a vague feeling of if something in that area goes wrong, it could be really bad? Laurence, do I understand you correctly that your main concern is ease of use for development and that decentralized version control would be preferable to a centralized one? Do you feel unduly blocked by the need to resolve these (rather tricky) legal issues? Might a technical solution be of use until this is resolved (git can read/write svn, can't it)? Wolfgang [1] Sorry, my English is failing me. I'm looking for a word that means, as opposed to formal. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 4, OK: 40, UNKNOWN: 2
* Tres Seaver tsea...@palladion.com [2011-11-19 14:31]: [1]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2011-November/052856.html [2]UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.6 : Linux https://mail.zope.org/pipermail/zope-tests/2011-November/052857.html These two are also tied to the missing zope.publisher 3.13.0 release. Mea culpa about the missing release; I don't actually know what happened, since I use zest.releaser, so there isn't all that much that should go wrong, usually. And I certainly didn't notice anything was amiss. Sorry about that. I've uploaded the release just now. [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052845.html We need to tie ZTK 1.0dev to a backward-compatible branch of zope.publisher (no longer the trunk). Ah. Right, that makes sense. 3.12.x then? Wolfgang -- Wolfgang Schnerring · email/jabber: w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting, operations signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope-tests - FAILED: 5, OK: 41, UNKNOWN: 1
* Zope tests summarizer nore...@zope.org [2011-11-18 02:00]:
[2]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit
https://mail.zope.org/pipermail/zope-tests/2011-November/052798.html
Module: zope.publisher.tests.test_testing
File
/home/ccomb/ztk1.0dev-slave/Python2.4.6-Linux-64bit/build/src/zope.publisher/src/zope/publisher/tests/test_testing.py,
line 33
with zope.publisher.testing.interaction('foo'):
^
SyntaxError: invalid syntax
I introduced this context manager in zope.publisher, fully aware that it
requires 2.5 at the least (which complies with the ZTK 1.1 specification
of 2.5--2.7).
Thus, I'm really confused why the builder for ZTK 1.0 is picking this up,
I've only bumped the version of zope.publisher in toolkit/trunk, nowhere
else.
Can somebody enlighten me what ZTK 1.0dev actually builds?
Thanks,
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser release?
* Wolfgang Schnerring w...@gocept.com [2011-10-28 08:43]: * Benji York be...@benjiyork.com [2011-10-26 16:42]: On Wed, Oct 26, 2011 at 10:26 AM, Wolfgang Schnerring w...@gocept.com wrote: I've added an assertion helper to zope.testbrowser that provides ``assertEllipsis``, which is very helpful when using Testbrowser with unittest.TestCase (instead of doctests). I'm +1 on the functionality, and -0 on the location. This would seem more appropriate in a general extensions-for-unittest package (like http://pypi.python.org/pypi/testtools). Actually, when you're putting it like this, I find myself in complete agreement. :-) I'll revert that from zope.testbrowser and probably start gocept.testing or somesuch instead. And here we go: http://pypi.python.org/pypi/gocept.testing/1.0 Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser release?
* Benji York be...@benjiyork.com [2011-10-26 16:42]: On Wed, Oct 26, 2011 at 10:26 AM, Wolfgang Schnerring w...@gocept.com wrote: I've added an assertion helper to zope.testbrowser that provides ``assertEllipsis``, which is very helpful when using Testbrowser with unittest.TestCase (instead of doctests). I'm +1 on the functionality, and -0 on the location. This would seem more appropriate in a general extensions-for-unittest package (like http://pypi.python.org/pypi/testtools). Actually, when you're putting it like this, I find myself in complete agreement. :-) I'll revert that from zope.testbrowser and probably start gocept.testing or somesuch instead. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.testbrowser release?
Hello,
I've added an assertion helper to zope.testbrowser that provides
``assertEllipsis``, which is very helpful when using Testbrowser with
unittest.TestCase (instead of doctests).
Some examples:
self.assertEllipsis('...bar...', 'foo bar qux')
# - nothing happens
self.assertEllipsis('foo', 'bar')
# - AssertionError: Differences (ndiff with -expected +actual):
- foo
+ bar
self.assertNotEllipsis('foo', 'foo')
# - AssertionError: Value unexpectedly matches expression 'foo'.
For convenience, if no ``actual`` value is provided,
``self.browser.contents`` is used.
I'd like to cut a release of zope.testbrowser, if nobody has any
objections against my doing so. There are also unreleased changelog
entries about handleErrors and WSGI, which look fine to me.
Wolfgang
--
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
signature.asc
Description: Digital signature
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-09-06 20:06]: On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote: * Chris McDonough chr...@plope.com [2011-09-01 04:27]: It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me. I guess this is the central issue where we have different opinions. I don't consider those just convenience, but rather concept-bearing of their on right. Convenience and concept bearing aren't mutually exclusive. Whom would be served if we moved the global API to zope.registry? Are you thinking that zope.registry would be some sort of fresh start for zope.component? If so, is anyone willing to promote it, write new docs, etc? Yes, I like the idea of a fresh start (or at least proper clean up) quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages. It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty. But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry. If we were to move all this stuff into zope.registry, I think we'd do just as well to leave zope.component as-is, but port all of its dependencies to Python 3. Isn't that a little too black and white? I find value in the idea of removing the dependencies to ZODB, ZCML and zope.security, while leaving zope.event/zope.testing in place. Although that's a noble goal, I personally won't be doing that any time soon; I'd instead just take the code we actually from zope.component and put it into Pyramid itself. I agree, porting the whole hairball is way too much, and I definitely wouldn't want to burden you/Pyramid with that. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-09-08 05:21]: On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote: Yes, I like the idea of a fresh start (or at least proper clean up) quite a bit. And I'd definitely be up for writing (new) documentation. You've set a great example in that regard with Pyramid that is very much worth emulating for other packages. I'm behind the goal of cleaning up and documenting componenty things better, and I think those are very worthy ideas. But I think blocking the proposed division while we hash out the details of what some second generation zope.component might be is probably not in anyone's best interest. If there were some branch laying around with a proposed set of changes, it might be more reasonable, but there's not, and it will take months to create one (after discussion, planning, development, rehashing, etc). The creation of a second package today that just holds the proposed bits doesn't prevent future innovation, AFAICT. I guess that extracting just a little bit right now won't get in the way of doing things properly (since that most likely means extracting a little more and then documenting it), and I certainly don't want to stand in the way there. However, that means that the package currently called zope.registry will quite likely become the future of zope.component. In that light I'd really like to try and come up with a better name -- Jim? Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-09-01 04:27]: It wouldn't be the end of the world to have the global registry and the global API live in zope.registry, but it doesn't help Pyramid for it to be in there, and it probably wouldn't help anyone else either. The global API (which includes getSiteManager) is really just a convenience feature, and splitting that global API across more than one package doesn't seem to make sense to me. I guess this is the central issue where we have different opinions. I don't consider those just convenience, but rather concept-bearing of their on right. It might make sense for the entire global API to be in zope.registry, but if you take global API to mean what it does now that implies dependencies on at least: - zope.event (zope.component.event.dispatch) - zope.testing (for addCleanUp of the global registry in z.c.globalregistry and other places) Yep, those two would be necessary. It also implies conditional dependencies on zope.security (in z.c.hooks.setSite, and other places), which are even now pretty nasty. But I don't see where that would come from. As far as I understand it, hooks.setSite wouldn't be in zope.registry. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Jim Fulton j...@zope.com [2011-08-30 09:25]: On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring w...@gocept.com wrote: My understanding is that from a client's perspective these two are equivalent: if you want the foo functionality for zope.component, you have to depend on zope.component[foo], and you import stuff from zope.component.foo. Except that probably many (most?) clients of zope.component don't bother to name the extras because they depend on the other dependencies anyway, for other reasons. Yes, right, I see that now. Thanks for clarifying! Hmm, I guess I'm going to lose if I try to argue that not naming the extra is wrong and thus deserves no respect or compatibility protection, am I not? Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-08-30 03:51]: On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote: My interpretation of your suggestion is that maybe that zope.component end up as what zope.registry is now. But I don't think preserving the name zope.component for this small core and spinning off everything else in the package into separate bits is very attractive, because zope.component is just a name and we can do it with a lot less churn and potential for bw incompat if we just rename the core bits rather than changing the meaning of zope.component to be just the core bits. Yep, that's a fitting assessment. I have two concerns, the more important one is to establish a clear definition of what concepts and functionality constitute the Zope Component Architecture (in other words, for the most part, what of everything that currently is in zope.component does actually belong there?) and to keep these core bits intact when we're extracting and/or pruning. The second one is that the established package name for the ZCA has been zope.component, and that I'd rather keep it that way. But I guess I'd be willing to concede that point and take up a new name, since I agree that trying to keep it probably requires more churn and headaches than changing it. But I also guess I'd like the new name to be more evocative than zope.registry. Yes, I fully realize the bikesheeding potential, and I'm sorry (a little at least ;-), but the ZCA is so much at the core of the Zope world I feel it deserves some consideration so as to carry a fitting name. By the way, while we're taking up new names and leaving zope.component intact as bw compat, can we use that opportunity to clean up the terminology a little? For example, class Components should IMHO become class Registry, and getSiteManager could be something like getCurrentRegistry. ** To take up the what is the ZCA question again, I don't know if this helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael Howitz and myself) brainstormed at the office whiteboard and came up with stuff the ZCA is used for in Zope3-ish applications: - Dependency Injection to promote inversion of control (utilities) - Multiple dispatch to promote extensibility (adapters) - Event handlers to promote decoupling (subscribers) - Plain old configuration (any of the above can be bent towards that purpose, my favourite example being how the default view name is handled... ouch.) - The notion of a context in which the application runs and that informs its behaviour (in Zope3 terms, the site; more on that below) These seem to be quite different things, and I'm not certain they *should* be all together in one place, but on the other hand, extracting zope.registry as proposed seems to me to take out just slices of each (think vertical stripes) and leave other parts of each behind in zope.component, which seems to me the wrong way around (horizontal stripes would be better). As far as I'm concerned, the ZCA global API and zope.event machinery are not guts; they are convenience APIs on top of the guts. Each promotes the idea that there is a single registry per process, which is not always true (it's not in Pyramid, anyway). I'd be a -1 on seeing these sorts of convenience APIs come along for the ride into the guts package, whatever that ends up being. I don't think zope.component.getSiteManager() promotes a single registry per process, but rather (although maybe just as jarring) the concept of a current registry. While personally I'm not so sure anymore that this is a Good Thing(tm), I feel it is quite fundamental to how zope.component is used and thought about. If you take this notion away, of a context in which code runs and which provides a current registry, no more IFoo(bar) and no more simple getUtility, but you'll have to explicitly retrieve or pass around the registry. (I guess Pyramid does it like that? The registry lives on the request and that is passed around throughout the framework?) Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
* Chris McDonough chr...@plope.com [2011-08-28 21:35]: Pyramid doesn't actually require ZCML or zope.schema; it only uses the parts of zope.configuration related to actions, conflict resolution, and the ConfigurationMachine itself. These bits have proven useful outside the context of ZCML and other schema-driven configuration. I have tackled this issue by factoring zope.configuration into two pieces: - I have moved the bits that don't rely on ZCML or zope.schema into a new 'zope.configmachine' package - I have made zope.configuration which depends on zope.configmachine in a branch: Splitting zope.configuration into core mechanics and ZCML support makes a lot of sense to me. I'm not too hot about the zope.configmachine name, because it's all mechanics and not much intention, but I realize the bikeshedding danger here. So, +1 from me. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Jim Fulton j...@zope.com [2011-08-26 07:35]: On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring w...@gocept.com wrote: * Jim Fulton j...@zope.com [2011-08-25 15:24]: stripping zope.component to its core would be backwards incompatible now. Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml]. But it still contains code to go with those dependencies. To clean this up, you'd have to remove that code, which would cause breakage. I have the feeling I'm missing or overlooking something. Could you help me find it? These are the two scenarios, as I understand them: a) zope.component declares an extras_require foo, making it depend on zope.foo, and also has a module zope.component.foo with integration code in it. b) zope.component declares an extras_require foo, making it depend on zope.foo *and* a new package zope.component_foo (which contains the extracted integration code). Also, zope.component has BBB imports in zope.component.foo that point to zope.component_foo. My understanding is that from a client's perspective these two are equivalent: if you want the foo functionality for zope.component, you have to depend on zope.component[foo], and you import stuff from zope.component.foo. The current zope.component, because it came out of the Zope3 monolith, That's not right. When Zope3 was managed as a single whole, zope.component was far more cohesive and less tangled than it is now. It gained a bunch of cruft in the rush to kill zope.app.component when code was moved from zope.app.component was mistakenly moved to zope.component. Ah, I wasn't properly aware of that part of its history. Thanks for clarifying! I think treating integration with zope.event as core would be reasonable. That makes sense. Event handlers certainly feel like a useful (and widely-used) feature to me. - zope.security - zope.configuration - ZODB In that light, it makes a lot of sense to me to have two (or more?) packages, core and integration, but I'd *very* much like them to be named in a way that one can tell this fact from their names. Me too. I wish the destruction of zope.app.component had happened differently. I'd like to have meaningful names, but I'd rather not incur more backwards incompatibility to get them. It's certainly valid to argue for the backward incompatibility. It's a tradeoff. I think I don't want to argue for incompatibility, but rather I am glad that we are exploring what degrees of freedom for improvement remain available to us while still preserving compatibility. What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core). IMO, what's core is a way to plug in component registries, not a particular strategy for component registries. Do I understand you correctly that the fact that getSiteManager is hookable should be core, but the thread-local mechanism of setSite() should not? That seems like a very useful delimination. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-08-26 13:27]: So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages. I'm -1 on redefining the meaning of zope.component. I'm afraid I don't understand what you're saying. Could you expand on this? What meaning is redefined to what by which proposed action(s)? Otoh, if the name zope.registry (or the introduction of a new package) is a problem, I'd suggest we move the stuff that is currently in zope.registry to zope.interface. zope.interface already contains a bunch of registry-related code; it'd make complete sense to me. That's an interesting suggestion, since zope.interface contains the bigger half of all the adapter mechanics already. (zope.interface would gain the concept utility, an adapter from nothing, but I wouldn't mind that, I guess.) However, my main driving point here is coherent package boundaries, and as said elsewhere in this thread, I think that the core of zope.component comprises more than just the Registry class, namely the (hookable) getSiteManager protocol and probably zope.event integration -- and I'm not sure that all this belongs into zope.interface. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
Hello Charlie, * Charlie Clark charlie.cl...@clark-consulting.eu [2011-08-26 11:17]: Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring w...@gocept.com: However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable. I think that what you suggest is too much for the moment and I think it even contains the Zope 3 risk of trying to get everything right. I fully agree that it is not feasible to do everything at once, and that we should take small but continuous steps towards the goal. But my aim was first and foremost to point out that the currently proposed step is going *in the wrong direction* in my opinion. Upon that it's a little disheartening to hear that I'm trying to do too much. Tres' proposal has the not inconsiderable advantage of merging work already done. This feels a lot like the facts are already there, end of discussion to me, and I hope you agree that this is not a reasonable argument. And, given that the work has come from an external if related project, the main aim of exposing these libraries to the wider world has been achieved. That is true and I'm glad we're leaving the monolithic state it's all of Zope or nothing behind more and more. However, to mention the goal again (which is worth moving towards, I think), I really think we should not split things up just so according to current mechanical requirements, but also think about conceptual boundaries. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Chris McDonough chr...@plope.com [2011-08-30 03:51]: If there's some solution that doesn't break bw compat but gets what you're after, I couldn't possibly be opposed to it. But I don't see how it can happen without some backwards incompatibility, even if that backwards incompatibility is the requirement that a user install setuptools extras to get what used to come along with the core. A. *slaps forehead* There's my thinking mistake. Currently, the extras_require is *not* necessary to get the integration bits, clients can depend on *only* zope.component. That would have to change with my idea, and that's not bw compatible. Right. I have to think this over (at least) once more. Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
* Jim Fulton j...@zope.com [2011-08-25 15:24]: On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring w...@gocept.com wrote: So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages. I would agree if we were starting over. But the damage is done and stripping zope.component to its core would be backwards incompatible now. Why? zope.component already uses extras_require to signify the various integration parts: [persistentregistry,security,zcml]. As far as I understand the thrust of the zope.registry effort, it is to untangle those to make porting easier (which requires those bits not to be in the same package, I guess, because of import problems or whatnot?). I think the same effect could also be achieved by splitting these integration bits into separate packages, and leaving the extras_require's in zope.component to depend on said new packages, couldn't it? But that's only technicalities in search of meaningfully preserving the name zope.component for the core package (because that's the name it always had), and... This is, OTOH, an opportunity to maybe come up with a more appealing name. While I like the term component, my sense is that it probably feels too heavy to a lot of Python programmers. Registry is at least as bad and doesn't reflect the real use case. ... I agree that an alternative is to give the core a new name. However, what's important to me is that we try to make packages cohesive, and that we try to make integration between packages understandable. The current zope.component, because it came out of the Zope3 monolith, contains integration bits to various other Zope packages: - zope.event - zope.security - zope.configuration - ZODB In that light, it makes a lot of sense to me to have two (or more?) packages, core and integration, but I'd *very* much like them to be named in a way that one can tell this fact from their names. What remains is the issue that zope.component *also* contains code for the thread-local site concept -- which doesn't feel like an integration with another package, but might not be considered core functionality, either (I'm not sure yet but I lean towards considering it core). Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
Hello, * Tres Seaver tsea...@palladion.com [2011-08-16 22:50]: The focus of the 2011 Pyramid GSoC project has been to port crucial Pyramid dependencies to Python3. At the end of this year's US PyCon, Lennart Regebro labelled[1] zope.component as high-hanging fruit, due to the following factors:: - magic - Mostly tested via doctests - Hairy dependencies (e.g., zope.proxy, zope.security) - Many more optional / testing dependencies (ZODB3, zope.schema, zope.configuration, etc.) Based on IRC discussion at project kickoff[2], Joel Bohman, one of the two Pyramid GSoC students, has tackled this issue by factoring zope.component into two pieces: - Joel has moved the core registry bits into a new 'zope.registry' package, now hosted in the Zope SVN repository: - Joel made zope.component depend on zope.registry in a branch: I applaud both the direction of porting to Python3 and the drive towards cleaning up / streamlining the ZTK packages. That's great! However, I feel that this extraction of the registry bits is a little too mechanical, and I'd like us to think a little bit about alternative approaches before we commit this. I envision the ZTK packages (like zope.component) to become more standalone, less coupled to the whole Zope world, but cohesive pieces of functionality that can stand on its own. In that light, I'd like to ask: what should be in zope.component, and what shouldn't? My first stab at an answer goes something like this: zope.component (aka the Zope Component Architecture) consists of - the Registry concept - filling out the Adapter concept of zope.interface - the Site concept (setSiteManager, aka hooks.py) - integration with zope.event (? a bit unsure here) Something like that would make a coherent, usable package, I think. At the moment, though, zope.component also contains (triggered via different extra_requires): - integration with zope.configuration (the adapter/ and utility/ directives) - integration with zope.security - integration with ZODB (persistent registries) Those integration bits with other parts of the Zope world don't need to be in there, I guess -- and as I understand it, precisely those are the hairy dependencies that impede porting to py3. So I'd like to propose to do the split the other way around: Not extract the core into something else and leave only a hollowed-out shell of integration and miscellany stuff behind, but rather tighten zope.component to its core and move the optional integration bits out of it, into separate packages. What do people think? Wolfgang -- Wolfgang Schnerring · w...@gocept.com · software development gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Python, Pyramid, Plone, Zope - consulting, development, hosting ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] fanstatic and preprocessors
Hi, is this the right place to ask stuff about fanstatic? Unfortunately I haven't had the opportunity to have a proper look at fanstatic (yet!), but I've just been reading about SASS and CoffeeScript, which are preprocessors/compilers for CSS and JavaScript. So I wondered whether it is within fanstatic's scope that one could feasibly write a plugin to support something like this. Something like, I drop a foo.coffee file somewhere and it would be run through the CoffeeScript compiler, probably cached, and served to clients as foo.js. (This thought has been triggered by what Rails is doing right now[1] which is powered by their equivalent resource manager[2].) Wolfgang [1] http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html [2] https://github.com/sstephenson/sprockets ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component test isolation
Hi, it seems to me this has stalled somewhat, so I wanted to ask what people's conclusions are. * Wolfgang Schnerring w...@gocept.com [2011-03-26 13:41]: * Martin Aspeli optilude+li...@gmail.com [2011-03-26 11:22]: On 26 March 2011 08:11, Wolfgang Schnerring w...@gocept.com wrote: I don't think a fixture of package foo's configuration except component X and Y is all that useful. Whether the the unregister use case is useful remains debatable, but I personally don't care all *that* much for it, so if the consensus is that it's overkill I'll go along I guess. I do care quite a bit for proper getSiteManager() support... We do definitely need to allow the global site manager to be stacked (which you can achieve with __bases__ as in plone.testing, unregistration notwithstanding). But once you do that, the rest is pretty easy. The local site manager will always have the global as one of its (nested) __bases__. I'm sorry, but no, it isn't that easy. When the only local site consumer is zope.site, well, maybe. But please think of this in terms of zope.component *only*. Its API is getSiteManager.sethook(callable), and AFAICT the contract is that the return value of callable must provide IComponents (briefly: get* and register*). Nowhere does it say that you have to delegate back to the global registry, and neither it should. To bring up Pyramid once again, they explicitly don't, because they want to allow several applications (thus, several registries) coexisting in the same process. And since we can't assume this delegation, I think there is no other way to properly do the stacking than to bend getSiteManager. ... as described here, though. And I wonder if I'm missing something, because to do that properly looks like quite the can of worms to me. So, how can we proceed here? Should I (and Thomas) try to get a proof-of-concept implementation of this based on plone.testing? Or should we think about what it takes to merge most of plone.testing's ZCA support into zope.component itself first? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New test summarizer format
Hi, * Adam GROSZER agroszer...@gmail.com [2011-03-29 11:15]: On Thu, 24 Mar 2011 10:51:44 +0100 you wrote: So. Theuni says, the code[1] (based on the current aggregator script) is probably pretty much ready for deployment. This is a script to be run by cron that scrapes the HTML list archives of the zope-test list. I haven't looked at it yet, so I don't know how ready probably pretty much actually means. [1] http://zope3.pov.lt/trac/browser/Sandbox/ctheune/testsummarizer If I understood this correctly, the current aggregator runs courtesy of Stephan Holek. I guess it would be a good idea to get this somewhere closer to the Zope Foundation, so I'd rather we work something out with Jens Vagelpohl how/where to run this than throw it up on one of our boxes here at gocept. Adam, do you want to tackle this? Otherwise, I can do it, but I don't know when I get enough round toits to make it happen. I'm rather busy nowadays. But it seems like it's about bugging Stephan Holek to stop the current one and bugging Jens to start the new one, or? Unless the script is broken. Could you run that script -- worst case we'll have 2 mails for a day -- for testing? Seems like it has the settings for gocept and I don't really have an SMTP server here handy. I'd really rather not duct-tape this... Alright, then I'll try and get it into running shape and bug people to run it. And unfortunately the code looks like it needs some work before it can be deployed properly. Wolfgang -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [buildout] private releases
* Christian Theune c...@gocept.com [2011-03-30 13:18]: On 03/30/2011 07:12 AM, Wolfgang Schnerring wrote: * Martijn Pietersm...@zopatista.com [2011-03-29 20:59]: On Tue, Mar 29, 2011 at 14:16, Adam GROSZERagroszer...@gmail.com wrote: ...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). (Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated egg server business required. So those solutions then require you to put the password for accessing it somewhere during deployment ... where is that for you? We put the password into the buildout.cfg. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [buildout] private releases
* Martijn Pieters m...@zopatista.com [2011-03-29 20:59]: On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote: ...and just dump the .tgz sdists in that folder. Well the problem is that it's not always so simple. For me a release process is preferably a single command or a single click on a button. Both zest.releaser and jarn.mkrelease offer you simple single-command release options. I use jarn.mkrelease to make releases to private, password protected folders on our dist.jarn.com 'egg server' (apache directory indexes). (Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for zest.releaser that allows uploading the created egg via scp. We use this to put our non-public eggs into a folder that's served (and htpasswd protected) by an Apache or somesuch, no complicated egg server business required. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test fixture concepts
Hello, * Martin Aspeli optilude+li...@gmail.com [2011-03-27 16:13]: On 27 March 2011 15:54, Uli Fouquet u...@gnufix.de wrote: The (limited) experiences with py.test, however, were awesome. Some points that are quite cool IMHO: [...] I agree wholeheartedly with what Martin has said about py.test vs. zope.testrunner. - Lots of setup code (unrelated to fixtures) can simply be skipped. No need to do the ``testsuite = complex-testcase-collecting`` over and over again. Maybe the main point of py.test. You don't need that for zope.testrunner either, of course, at least not when using unittest base classes. This is a point that bears repeating, though: test_suite() is *not needed* since zope.testing-3.8.0 (2009-07-24) for descendants of unittest.TestCase. FWIW, I think we should stop using .txt doctests for unit tests. Doctests should be used to test *documentation* (the examples are valid). For actual unit tests, writing tests in a unittest class is almost always better in the long run. +lots and lots and lots, especially since you've formulated it in quite a balanced way. For now I think that there is absolutely no need to think about a general move to py.test for the ztk. I think there's benefit in unifying the concepts and support for concepts like layers so that people can use the test runner they prefer. How can we make progress here? I'm not sure whether this calls for some green field sketching, how should test fixture setup work? or some hands-on experimentation, let's see how we get some existing test layers to run under py.test, or both, or something else entirely. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test fixture concepts
Hello, * Jim Fulton j...@zope.com [2011-03-28 10:04]: More generally, I'd love to see us adopt another test runner so that we can stop maintianing zope.testrunner. When it was written at the turn of the century, there weren't good alternatives. Personally, I think maintaining it is boring. I agree, it would be nice to get out of the test runner business, just as we're getting out of the networking business more and more courtesy of WSGI. But I'm wary of throwing out the baby with the bathwater, zope.testrunner has quite a few features under the hood that are really useful, which I'm not sure other test runners have, and I definitely wouldn't want to lose. Layers are the most prominent, of course, but then there's post-mortem debugging (-D), coverage integration, ... the list goes on for a few more items, I'm certain. I guess, apart from the layer issue (see other messages in this thread), some research and write-up would be a good idea to get a feeling what the other test runners are like and how they measure up against zope.testrunner. A quick google search turns up nothing appropriate, so I might do a comparison of zope.testrunner, py.test and nose, but that's going to take a while. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope world
Hello, * Sebastien Douche sdou...@gmail.com [2011-03-28 13:26]: On Sat, Mar 26, 2011 at 15:18, Wolfgang Schnerring w...@gocept.com wrote: An honest counter question: Why not use zope.testrunner? What advantages does py.test offer? On the technical side, I don't know. But from my point of view, the most important thing is the social side. I'm a bit tired to be compartmentalized : you must use generics tools (Nose, WebOb, Paster...) or Zope tools (Zope3, KGS, zope.testbrowser, zope.testing, zc.buildout, z3c.testsetup...). I'd like to clarify that I've asked the question not to exclude py.test, but on the opposite, to *include* it into consideration. So I think we're actually in agreement with each other. :-) Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component test isolation
Hello, * Martin Aspeli optilude+li...@gmail.com [2011-03-25 13:58]: plone.testing (which is Plone non-specific and will shortly be BSD licensed) allows for stacking of ZCA registries. [...] Again, plone.testing is the result of hours and hours of finding weird problems, so I'd recommend you don't discard the knowledge there. I think a best case scenario would be for plone.testing.zca to just be a delegate for something more robust in zope.component.testing. I wasn't aware plone.testing had something for the ZCA, before I read that in this thread yesterday. I'm glad to hear that, and I certainly don't want to discard anything. But from reading the code and what you wrote, I get the impression that plone.testing does not yet solve the issue completely, precisely because of the two points I brought up and that continue below: On 25 March 2011 13:17, Jim Fulton j...@zope.com wrote: On Fri, Mar 25, 2011 at 4:24 AM, Wolfgang Schnerring w...@gocept.com wrote: we realized that just squeezing in a new registry and bending its bases to the previously active one is not enough for full isolation, since this does not cover *deleting* registrations Is deleting registrations important? This seems like an odd use case. If it's needed, I would suggest starting with a baseline (e.g. stack) that doesn't include the component you want to test deleting, then adding in setup. I've wanted to specifically nuke registrations sometimes, the pattern being, load the package's configure.zcml in the layer, and then delete something (to demonstrate some error handling behaviour). I agree that this use case is rare, but I'm not sure it is rare enough that we should ignore it. I need to think about this some more, though. 2. zope.component has two entry points, the global site registry and the current registry (getGlobalSiteManager and getSiteManager). The current registry can be anything, or more precisely, you can call getSiteManager.sethook(callable) and provide a callable that returns the current registry. I think to provide test support for zope.component (i. e. generally, at the library level), we need to support both entry points. Why? Why would someone care about anything other than the current effective configuration. Because that's the API that zope.component offers, it conceptually deals with *two* registries: the one you get from getSiteManager and the one you get from getGlobalSiteManager. I agree that it is unlikely that client code will *read* registrations using getGlobalSiteManager -- since most everyone uses zope.component.getUtility etc. (which in turn uses getSiteManager). But *writing* is a different matter. Just one example: zope.component.provideUtility etc. uses getGlobalSiteManager, while the ZCML directives use getSiteManager. At least as long as zope.component.provide* uses getGlobalSiteManager instead of getSiteManager, I maintain that test infrastructure needs to 1. wrap the global registry 2. wrap whatever getSiteManager currently returns (Otherwise we might be able get away with not doing (1), but I think we'll always need to do (2).) plone.testing has it the other way around, doing (1) but not (2), as Martin says himself... The global one is not hard, but the getSiteManager one gets nasty really fast, because of course we have to rely on bending getSiteManager to return the current test registry I don't think you need to do that. plone.testing doesn't, for sure, it just changes the variable that getSiteManager() looks at. ... and I'm quite sure that's wrong, becasue it doesn't deal with the issue of getSiteManager at the level of zope.component, but at the level of some specific implementations (zope.site and five.localsitemanager, to be precise). When I'm using, say, Pyramid (which also uses getSiteManager.sethook), this won't help me at all. And to do this on the level of zope.component, I'm quite sure we are going to need to override getSiteManager. but anyone could at any time call getSiteManager.sethook to change it! Seriously? Nobody calls that but deep infrastructure code. Agree with Jim. Are you going to stop people monkey patching getSiteManager() too? ;-) My point is: Ensuring that test setup always and everywhere happens precisely so that the code that calls sethook (for example the setup of zope.site) is called *before* the envisioned test infrastructure code comes along to bend getSiteManager to do its will seems very fragile to me, if it's doable at all. Wolfgang -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https
Re: [Zope-dev] zope.component test isolation
Hello, * Martin Aspeli optilude+li...@gmail.com [2011-03-26 11:22]: On 26 March 2011 08:11, Wolfgang Schnerring w...@gocept.com wrote: * Martin Aspeli optilude+li...@gmail.com [2011-03-25 13:58]: Please also take my word for it when I say that copying the whole registry is non-trivial and would rely on brittle ZCA internals. I tried. :) I tried, too, and yup, in the end you'd have to write C to do it properly (because the AdapterLookupBase or something in zope.interface is written in C and would need to gain __deepcopy__ support). But it didn't seem unfeasible, and, when it was all said and done in Python, not very ugly either. I appreciate that you've already fought (and won!) against the whole persistence story (which hadn't even been on my radar so far), and I guess copying would necessitate reopening that can of worms. I've wanted to specifically nuke registrations sometimes, the pattern being, load the package's configure.zcml in the layer, and then delete something (to demonstrate some error handling behaviour). I think you either need to consider a package's ZCML-loaded configuration as an atomic part of test setup, or you need to break it down into individual registrations. In the first case, your test fixture is package foo's configuration is loaded, which is of course valid. In the second case, your fixture is the following components, some of which happen to be in package foo, are registered. I don't think a fixture of package foo's configuration except component X and Y is all that useful. It seems I can't convey why I think that precisely this is valuable even without taking into account the desire for non-leaky abstractions (in the ZODB-analogy it would be quite strange to have to write on top, please don't delete stuff, it's not supported). And of course I know how one could work around the limitation that unregistering is not supported. That doesn't make it any less inconvenient. The other point about getSiteManager below is *much* more important than unregistration support, though: Because that's the API that zope.component offers, it conceptually deals with *two* registries: the one you get from getSiteManager and the one you get from getGlobalSiteManager. I agree that it is unlikely that client code will *read* registrations using getGlobalSiteManager -- since most everyone uses zope.component.getUtility etc. (which in turn uses getSiteManager). But *writing* is a different matter. Just one example: zope.component.provideUtility etc. uses getGlobalSiteManager, while the ZCML directives use getSiteManager. At least as long as zope.component.provide* uses getGlobalSiteManager instead of getSiteManager, I maintain that test infrastructure needs to 1. wrap the global registry 2. wrap whatever getSiteManager currently returns (Otherwise we might be able get away with not doing (1), but I think we'll always need to do (2).) plone.testing has it the other way around, doing (1) but not (2), as Martin says himself... We do definitely need to allow the global site manager to be stacked (which you can achieve with __bases__ as in plone.testing, unregistration notwithstanding). But once you do that, the rest is pretty easy. The local site manager will always have the global as one of its (nested) __bases__. I'm sorry, but no, it isn't that easy. When the only local site consumer is zope.site, well, maybe. But please think of this in terms of zope.component *only*. Its API is getSiteManager.sethook(callable), and AFAICT the contract is that the return value of callable must provide IComponents (briefly: get* and register*). Nowhere does it say that you have to delegate back to the global registry, and neither it should. To bring up Pyramid once again, they explicitly don't, because they want to allow several applications (thus, several registries) coexisting in the same process. And since we can't assume this delegation, I think there is no other way to properly do the stacking than to bend getSiteManager. Wolfgang -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Test fixture concepts (was: Zope test layers, pytest, and test isolation)
Hello, part two. :) * Uli Fouquet u...@gnufix.de [2011-03-24 01:05]: A big advantage of test layers over `pytest` testing scopes might be that you can spread your tests associated to a certain layer over many files/modules/packages as you like and the setup/teardown will nevertheless only be performed once for each layer Compared to Zope test layers I came to the conclusion that there is not much like this concept already in `pytest` and the behaviour of test layers can not easily be faked. I fully agree, the test layer concept of zope.testrunner provides some very nice properties, most notably: 1) Shared fixture setup. It is shared across many TestCases and created only once per test run. (And it is independent of how the tests are organized into modules or whatever.) 2) Stacking of fixture setups. My canonical example: First, we initialize the application, load ZCML, prepare databases, etc. and talk to it with zope.testbrowser. That's the first layer. Then we add a HTTP port with gocept.selenium on another layer and do the rest with a real browser -- but the whole, possibly expensive, application setup *does not have to be done again*. 3) Orthogonal composition, i.e. you can have small, well defined fixture units that you can then combine in a separate step to form the actual setup for your tests. This enables for example that library packages like zope.component could provide test infrastructure for themselves, and application packages could pull all the test infrastructure together that they need -- not like zope.app.testing for example, which is a giant monolith that sets up everything at once. I think that these properties are very valuable, and I haven't seen them anywhere else so far. I haven't looked at py.test closely, yet, but from what I've seen, and what you wrote, it doesn't seem to offer these things right now. Would it make sense to bring the Zope layer concept into `pytest`? Are there already possibilities to mimic testlayer-like behaviour in `pytest` which we simply overlooked? An honest counter question: Why not use zope.testrunner? What advantages does py.test offer? But your email brings into focus a question that I've been thinking about lately: What's the future direction for test fixture setup? Because, while test layers are nice because they have the above properties, I'm not too happy with the current implementation, namely the use (or is it abuse? ;-) of __bases__ and __name__, which leads very naturally to not-so-helpful implementation patterns. As a concrete example, some of the test layers of ZTK packages, most notably the successors of zope.app.testing.functional in zope.component, zope.app.appsetup, zope.app.wsgi, are implemented right now in a way that does not have properties 2+3. The most straightforward way to improve that situation would be to use plone.testing, since that provides a layer implementation that is both sane and easy to use, and has all the nice properties. (Maybe even fold some of it into zope.testrunner itself.) But then I realized, that's a major undertaking, so we better think about what the actual goals are before changing lots of stuff. And then I heard people expressing interest in other test runners. (py.test and nose seem to be the biggest players, stdlib's unittest/unittest2 seems to be woefully behind in terms of test selection and other features like coverage or debugging. I for one happen to like zope.testrunner, but if there's a good alternative, why not combine our efforts?) I also found that it is rather hard to explain how to use test layers in a way so you actually get the above properties, so I started wondering whether there was a cleaner way to get them. So I guess I have three questions: 1. (The starting point:) How can we improve the test infrastructure situation of the ZTK packages? 2. (The main thing:) Are test layers, both the concept and the implementation as epitomized by plone.testing, the way to go or is there a cleaner alternative? 3. (But only tangentially, I don't want to sidetrack the discussion at hand nor start a flamewar:) Is there a compelling alternative to zope.testrunner that would make it worthwile to think about either generalizing the fixture support or even migrating away from zope.testrunner? Wolfgang -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.component test isolation (was: Zope test layers, pytest, and test isolation)
Hello Uli, I've spent quite some time thinking (and partly coding) about the same issues you mention (but didn't feel ready to talk about it here, yet), so I'm glad that maybe we can start thinking about them together I think your email addresses two quite different topics, so I'll split my reply. First up: test support for zope.component. Second part: about the concept of test layers. * Uli Fouquet u...@gnufix.de [2011-03-24 01:05]: Right now we have a problem with pytest integration when it comes to ZCA setups [...] all tests share the same global ZCA registrations and changes to the registrations in one test will affect other tests run thereafter. We have a lack of test isolation. Exactly. This issue has bitten me too in various places, and as far as I know there are no solutions for it, yet. What I envision to solve this issue is that test support for zope.component should work the same way as with the ZODB. There, we have a *stack* of Databases (DemoStorages, to be precise) that wrap each other, where each one delegates reads downwards, but keeps writes for itself. So you might have one database for the layer that provides the baseline, and each test (in its setUp) gets its own database where it can do whatever it wants, because it is thrown away in its tearDown. In principle, quite a few of the mechanics to do the same thing with zope.component registries are already there (since a registry keeps a list of base registries it will delegate to when something can not be found in itself). And as Hanno and Godefroid mentioned, plone.testing does something in this direction already. (And, it bears repeating, in its core has no dependencies on Plone or Zope2.) But as far as I see, there are issues that plone.testing does not address: 1. I've been going over this stuff with my colleague Thomas Lotze, and we realized that just squeezing in a new registry and bending its bases to the previously active one is not enough for full isolation, since this does not cover *deleting* registrations (one, you can only delete the registration from the precise registry it was created in, and two, in the just-bend-the-bases approach, once you delete a registration, it's gone forever). I think to provide full isolation, we need to make *copies*. And since zope.component in general supports a chain of registries, we probably need to make copies of each of them. 2. zope.component has two entry points, the global site registry and the current registry (getGlobalSiteManager and getSiteManager). The current registry can be anything, or more precisely, you can call getSiteManager.sethook(callable) and provide a callable that returns the current registry. I think to provide test support for zope.component (i. e. generally, at the library level), we need to support both entry points. The global one is not hard, but the getSiteManager one gets nasty really fast, because of course we have to rely on bending getSiteManager to return the current test registry -- but anyone could at any time call getSiteManager.sethook to change it! Which means we need to intercept that and a) prevent our hook from being replaced and b) inject the new registry into the test stack somehow. As far as I understand, plone.testing sidesteps these issues by only dealing with the global registry, and specially munging the two known cases in the Zope world where getSiteManager is changed (zope.site and five.something). ** I'd like to know what people think about this plan. Thomas and I have been over this quite a bit and think it's sound, not overly complicated, and (after we did some experiments) definitely doable. Please do point out stuff we missed. :-) I'd very much like to put this functionality into zope.component itself, which of course raises backwards compatibility issues galore, but any code for this definitely isn't wasted since we can always package it separately if we don't find a way to integrate it. Thomas and I taken up implementing this, but we can't devote a lot of time to it (about one session per week), so realistically I'm afraid I guess it will take a few months until we have something of substance. So if there are people who want to pitch in, that'd be great. I definitely could write up a more detailed plan and maybe even formulate smaller chunks so we could go at this with more people. Wolfgang -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New test summarizer format (was: We need to get the board green)
Hello, * Adam GROSZER agros...@gmail.com [2011-03-23 08:45]: On Wed, 23 Mar 2011 07:43:26 +0100 you wrote: On a tangentially-related note, what happened to the proposed new summarizer formatting? Half a year ago (or whenever), I got the impression it was going to be ready in a few days, but it seems it never happened. What is needed to get this switched? You mind walking over to Theuni and asking him? ;-) Oh. Right. Sure. *walks over and back* So. Theuni says, the code[1] (based on the current aggregator script) is probably pretty much ready for deployment. This is a script to be run by cron that scrapes the HTML list archives of the zope-test list. I haven't looked at it yet, so I don't know how ready probably pretty much actually means. If I understood this correctly, the current aggregator runs courtesy of Stephan Holek. I guess it would be a good idea to get this somewhere closer to the Zope Foundation, so I'd rather we work something out with Jens Vagelpohl how/where to run this than throw it up on one of our boxes here at gocept. Adam, do you want to tackle this? Otherwise, I can do it, but I don't know when I get enough round toits to make it happen. Wolfgang [1] http://zope3.pov.lt/trac/browser/Sandbox/ctheune/testsummarizer -- Wolfgang Schnerring · w...@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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] We need to get the board green
* Tres Seaver tsea...@palladion.com [2011-03-21 16:56]: Too many never-resolve failures in our buildbots makes their output just noise: the amount of effort required to diagnose the cause of a failure seems to have no payoff if we don't get them each cleared up. On a tangentially-related note, what happened to the proposed new summarizer formatting? Half a year ago (or whenever), I got the impression it was going to be ready in a few days, but it seems it never happened. What is needed to get this switched? (I'm not saying dressing the continuous failures up nicer is a solution to the problem Tres is presenting, but I do think the noisy format contributes to the confusion about the buildbots) Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
Hello Brian, it's taken a while, but I finally had a chance to review your branch(es). * Brian Sutherland br...@vanguardistas.net [2011-02-12 18:57]: On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest I pulled this out of my original branch and put it here: svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal Thanks, that helped me understand what's going on much better. I do have a few questions about this part: - Does the (webtest-based) wsgi.Browser behave similarly to the Publisher-Browser? When we ported the wsgi_intercept variant from zope.app.wsgi, we found that there were some idiosyncracies woven in that people may rely on. This kind of stuff of course isn't documented, and we didn't do much research, but rather took care to port what we found in zope.app.wsgi, namely filtering some HTTP headers from the response (meh, doesn't feel important), and handling Basic Auth headers (that feels important to preserve). - What should happen in zope.app.wsgi? We moved the wsgi-based Testbrowser from there and left BBB imports to zope.testbrowser.wsgi, taking care to be API compatible. I guess that won't be possible with the WebTest-based Testbrowser (or would it?), so we probably have to break that. (Hmm, would that imply a major version bump there, too?) Since the Grok people are the ones who probably use the zope.app.wsgi Testbrowser the most, they should probably take the WebTest-Testbrowser for a test drive and see whether it works for them, otherwise we're going to make them quite unhappy if we just break zope.app.wsgi. (Could you ask on grok-dev about that? I guess it's too buried here to be noticed.) - What's connection.py? I don't really understand where that came from or what its purpose is, especially since wsgi.py seems to be the only one that uses it? Ah. I take that last bit back, the extracted Publisher-Browser in zope.app.testing uses it, so I guess this is a split-off artifact of the refactoring/extraction. But I still don't really understand what it is all about. %-) - The layer looks good. (OK, so that's not a question ;) I'm glad you found a way that the browser can get the application out of the air. I've tried the explicit passing way on a project of mine, and it's a huge hassle (I've ended up stuffing a preconfigured browser instance into the doctest globs, ugh.) I think it would be good if the layer stored the application of self.app, we did that in the wsgi_intercept variant and were glad of it a few times already. b) extract the testbrowser part that talks to the Publisher This is here and by necessity includes the changes for step (a): svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser The extraction of the Publisher-Browser makes a lot of sense, and looks clean to me, as does the rewrite of the tests to use a plain WSGI app instead of a Zope-based app. I would much prefer to merge both steps together. Yes, I guess that makes sense because only step (b) includes proper tests for everything. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
Hi, sorry I'm replying this late. I've been busy, then sick, then busy again, so I'm afraid this has got pushed low on my stack of stuff... * Brian Sutherland br...@vanguardistas.net [2011-02-02 11:15]: On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: * Brian Sutherland br...@vanguardistas.net [2011-01-31 09:54]: On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: Ok, I think that that API is preservable. However I would like to make the layer optional by adding an wsgi_app keyword argument to Browser. So you can do: browser = Browser(wsgi_app=app) where app is a WSGI application. Some people in the non-zope world are not too fond of layers, or use incompatible testrunners. We shouldn't force layers on them. Yes, we definitely don't want to require layers here. This has not been an issue so far, since both the publisher and the wsgi_intercept method inject the application to the browser by looking it up via the special hostname 'localhost', but now we need to pass in the WSGI callable explicitly. I do think that mostly one will want to prepare the WSGI callable only once, and thus a layer is a good fit, but that should be optional. I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest b) extract the testbrowser part that talks to the Publisher Initially I did them together because it was the only way to get very good test coverage of the WebTest integration. If we do it this way, between steps a and b we'll have poor coverate. But that's not so bad as the code has already been well tested on my current branch. As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept. I'll try make a branch for this in the next week or so for you to review. Thanks very much, I'll look throught it as soon as I find some time, probably not next week (I'm travelling), but hopefully the week after that, at the latest. As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about. Sure! As we've discussed off-list, we now both feel that moving the publisher-testbrowser to zope.app.testing is a good idea, since the only applications that will want to use that testbrowser are those that use zope.app.testing -- the more modern approach of testing publisher-based applications is to use the code from zope.app.wsgi to create a WSGI application and then use the WSGI-enabled testbrowser to talk to that. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
* Wichert Akkerman wich...@wiggy.net [2011-01-31 09:46]: On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other? If I remember correctly WebTest wraps the WSGI app object directly and does not require monkeypatching urllib. To send requests to the app under testing you call WebTest post/get methods, which directly call the WSGI app. Thanks for clarifying, that does indeed make sense. I guess I should have researched wsgi_intercept and WebTest in more detail. :/ * Brian Sutherland br...@vanguardistas.net [2011-01-31 09:54]: On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote: I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose. We have already committed to wsgi_intercept integration for the long term. It was released in zope.testbrowser 3.11 a few days ago, right? If we are to have only one way to do this, then wsgi_intercept must be it. I definitely don't see this as set in stone, *at all*. Yes, we've had a release that uses wsgi_intercept for talking to WSGI apps. (And yes, we didn't ask anyone for their opinion on it, and I'm sorry about that. However, I guess the development process in the Zope community is an entirely different issue, sigh.) But I feel the important point about this regarding compatibility is not the underlying technology, but the API, i. e. that - zope.testbrowser.wsgi.Browser is a Testbrowser - zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to facilitate the test setup. I think as long as we preserve this API (which seems sound to me, but of course I'm biased ;-), we're free to change stuff under the hood. But I'm ambivalent about only having one way to do things. I think having both integrations in zope.testbrowser is not such a bad thing. Having the test suite run over 2 different integrations is definitely good. Maybe I'm missing something, but when I think about the task at hand from the client's perspective, then the only sentence that matters to me is, give me a zope.testbrowser that talks to this WSGI callable. Which means a) I couldn't care less how that's done internally as long as it doesn't cause me any hassle and, more importantly b) I do *not* want to have to think about it and/or make a choice about the underlying mechanism. I want the library to have done that research (as we are doing right now). And to me this task seems straightforward enough to not warrant pluggability -- on the contrary, I feel it's so narrow in scope it outright *forbids* it (but again, I may be missing something). I'll gladly review your branch, but I'd like to know the motivation behind it. Only ~30% of the branch is the implementation of the WebTest connection. The other ~70% of the branch is a refactoring of the test suite. That's where the reduction in test dependencies comes from. The test fixture on the branch is a reasonably minimal WSGI application run via the WebTest connection. I'd prefer if we treated this as two separate steps, then: a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest b) extract the testbrowser part that talks to the Publisher As to (a), I'll still need to look at your code, but as I said I'm all in favour of using WebTest instead of wsgi_intercept. As to (b), I saw you moved the code to zope.app.testing. I have a few ideas in that area which I'll contact you off-list about. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
* Brian Sutherland br...@vanguardistas.net [2011-01-30 16:04]: I've finally finished refactoring my WebTest/testbrowser branches, basically doing this: - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new Browser implementation that uses webtest.TestApp to drive a WSGI application. This allows simple and direct testing of WSGI applications. - Re-write the test application as a pure WSGI application using WebOb. Run the existing tests using the WebTest based Browser - Move zope.app.testing based Browser into zope.app.testing (leaving backwards compatibility imports in-place). This is a very big change, so I would appreciate anyone who would take a look at these branches before I merge: Michael Howitz and I recently polished the integration of zope.testbrowser and wsgi_intercept to accomplish pretty much the same things you mentioned. (I'm aware that you two exchanged some emails about it, but don't know any details). So I'm curious: What are the differences bewteen WebTest and wsgi_intercept? Is one preferable to the other? I'd very much like there to be *one* way of doing WSGI with the testbrowser, and at first blush I don't care whether that's WebTest or wsgi_intercept or whathaveyou, as long as it fulfills its purpose. I'll gladly review your branch, but I'd like to know the motivation behind it. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form buildout broken
* Roger d...@projekt01.ch [2010-11-22 14:30]: Probably an option like --skip-part omelette whould be a nice feature for buildout. IIRC, when the parts are originally specified on separate lines base.cfg: [buildout] parts = like this omelette #not: parts = like this you can do this: buildout.cfg [buildout] extends = base.cfg parts -= omelette Don't know whether/how you can do that on the command line, though. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and python2.7
Hello, * Jan-Jaap Driessen jdries...@thehealthagency.com [2010-10-14 19:19]: The httplib.HTTPConnection API changed from python2.6 to python2.7. These changes are reflected in the handleErrors property of zope.testbrowser.browser.Browser - it is no longer possible to pass a boolean into the request headers. Thanks for looking into this. Forward compatibility is a good thing. A fix is available on the trunk of zope.testbrowser [1]. In this implementation, a boolean is provided to the consumers of the testbrowser API and a string is used in the request headers. This implementation is sub-optimal in my opinion. In the branch 'janjaapdriessen-handle-errors' [2] you will find a cleaner implementation, where the switch to handle_errors is controlled by the presence of a zope-do-not-handle-errors header. I agree that the boolean-string translating is a bit ugly, but to be honest, I also don't not dislike the double negative in your alternative solution. ;-) This change is backwards incompatible. Code relying on the 'x-zope-handle-errors' header will break. I have tested this implementation against the ZTK trunk on python2.7 and have found no breakage of this kind. I'm definitely fine with changing that header name if necessary, though. Since that's an implementation detail of zope.testbrowser, it should be nobody else's business, and your tests seem to confirm this -- excellent. Please let me know if either of these solutions is OK with you. If so, grant me pypi rights (my handle is 'janjaapdriessen') so I can release zope.testbrowser and get a step closer to making the ZTK run on python2.7. I don't have a *strong* opinion which serialization of that flag is less ugly. I'm leaning towards the trunk one (no double negatives), but either one is basically fine by me. I've given you pypi rights for zope.testbrowser. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.compattest buildout 1.5/1.4 compatibility
* Jan-Wijbrand Kolman janwijbr...@gmail.com [2010-10-06 13:39]: On 10/6/10 12:49 PM, Wolfgang Schnerring wrote: * Jan-Jaap Driessenjdries...@thehealthagency.com [2010-10-05 18:09]: Version 0.12.2 of z3c.recipe.compattest is not compatible with recent versions of it's dependencies zc.buildout (v1.5.1), zc.recipe.egg (v1.3.2) and z3c.recipe.scripts. I fixed this in revision 117253. Is it OK with you to drop compatibility with zc.buildout versions 1.5 in the next release of z3c.recipe.compattest? I'm all for moving forward, but I don't really understand why the 1.5-update should cause such compatibility breakage. I think in this particular case z3c.recipe.compattest relied on zc.buildout internals that now have have changed. So, no, I do not think it really is an API change and as such it is not intentional breakage nor something that __should__ be fixed in buildout. Ideally, z3c.recipe.compattest would be fixed in such a way that is does make use of official buildout APIs. Thanks for the explanation! I agree with you, it would make a lot of sense to use official APIs and not work around them. Don't know how hard that's going to be in this case, though. ;) Still there's the case that quite some recipes need to be updated to zc.buildout 1.5.x if they want to use its new features (system python support). Ah. I didn't remember that compattest indeed does generate scripts (I thought it was delegating everything, but that's not correct of course), and I didn't understand from Jan-Jaaps email that system-python-support was a goal here, too, I only got the some compatibility broke part and was confused about that. BTW, I discussed updating the z3c.recipe.i18n for similar reasons - to support newer buildout features - in a separate thread. There people seemed to be +1 on releasing a recipe that declares its minimal buildout version requirement to be = 1.5.1. Would you say that that situation is similar to this? Yes, I agree, that makes sense, so +1 from me here. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.compattest buildout 1.5/1.4 compatibility
* Jan-Jaap Driessen jdries...@thehealthagency.com [2010-10-05 18:09]: Version 0.12.2 of z3c.recipe.compattest is not compatible with recent versions of it's dependencies zc.buildout (v1.5.1), zc.recipe.egg (v1.3.2) and z3c.recipe.scripts. I fixed this in revision 117253. Is it OK with you to drop compatibility with zc.buildout versions 1.5 in the next release of z3c.recipe.compattest? I'm a little confused what's going on here. Could you explain this with a bit more details? I think my main questions are - Where and when, exactly, did which API change (it's related to recipe options AFAICT from the diff) - What does this have to do with buildout 1.5? - Is it a) really the case and b) intentional that buildout 1.5 breaks compatibility with 1.4? (Thus, can't this be avoided, possibly by fixing buildout 1.5?) I'm all for moving forward, but I don't really understand why the 1.5-update should cause such compatibility breakage. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Help review #181754
* Wichert Akkerman wich...@wiggy.net [2010-07-20 19:28]: On 2010-7-20 18:15, Christian Theune wrote: At least, WRT this bug, I don't think it's a good idea to ask explicitly for bad requests to go to the application as the test layer should model real server behaviour as closely as possible. And again it wouldn't make sense anyway as you can't pass an unparsable request to the application. I'm not sure I agree. Like everything else servers have bugs, so it can't hurt to test how your application would behave given certain server bugs. I don't think it is usually a productive assumption that lower layers fail to uphold their end of the contract. Maybe an extrapolation/hyperbole illustrates my opinion: Cosmic rays might also flip bits in your computer's RAM or disk, but I don't think it's worthwile to test how your application reacts when the python interpreter (or whoever, really) presents it with mangled data structures or objects or whatnot. To put it differently, yes, servers have bugs, but the place to fix them is in the server. If we can't rely on our layers/abstractions to hold, I feel we lose most if not all benefits of having them in the first place. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Bug tracker for zc.table
Hello, I've stubmled upon an issue in zc.table, it can't deal with spaces in column names when sorting (since it uses space as the field separator to pass the sort_on information). I don't have time to look into this right now, but I'd like not to forget it. Is there someplace on Launchpad where I could file a bug for future reference? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of this weeks' meeting (2010-03-30)
* Christian Theune c...@gocept.com [2010-03-31 17:16]: we decided to keep going with the meetings, so I'd be happy to see you guys next week in #zope. I'm all in favor, it seems to me the meetings really help in moving things along. For those of you who can't/don't participate in those meetings, there's the open question about how useful you consider my summaries to be. Please tell! I feel the summaries are essential: without them, those not able to participate would very soon be out of the loop, and that's a very Bad Thing(tm) in my opinion. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] quitting the ZTK steering group
* Martijn Faassen faas...@startifact.com [2010-01-22 22:27]: This is to announce my withdrawal from the Zope Toolkit steering group. I'm saddened to hear this. I feel that many if not all of the things you were trying to set in motion in our community are desperately needed. I'm sorry to hear that you have been worn out trying. Thanks for all the energy you've put into this. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] A summary of Interfaces vs ZCA concepts
* Martijn Faassen faas...@startifact.com [2009-12-17 17:48]: * Thomas Lotze t...@gocept.com: zope.interface [should be] completely unaware of any particular uses of interfaces Why is it a problem that the zope.interface package gains knowledge about adaptation (which it always had, anyway) and utility lookup? This is the key issue, I think. (And I'd like to ask you not to argue it has always been that way, since what we're trying to do here precisely is to improve the status quo.) The question is, which concepts belong into zope.interface and which don't? One might also phrase that as, what is the responsibility and purpose of zope.interface (drawing upon the software engineering terms of cohesion and coupling). My opinion is that [__call__ introduces] the following notion into zope.interface: please look up an object that provides this interface, somehow. (with zero or more context objects) might well belong into zope.interface, but that anything of these: adapters, utilities, null-adapters or contextual utilities absolutely do not. I think there is a clear distinction between what interfaces are about and what component architecture is about, and I think it is worthwile to maintain and clarify that distinction. For me, a notion of looking up something that provides an interface belongs to what interfaces are about. But notions of utilities which might or might not be singletons, of adapters which might or might not take additional parameters such as a name to look them up, or notions of a context or a registry (which for me comes up immediately when thinking about global vs. local utilities) that influences the lookup, for me emphatically do *not* belong to what interfaces are about. By putting method stubs into zope.interface which are exclusively about concepts of zope.component we would be a) On a conceptual level: blurring the distinction between the two packages and concepts, which I think is a Bad Thing(tm) b) On a more practical level: coupling zope.interface to zope.component. Given all the recent efforts of untangling the dependency structure between our packages, I think doing that would be a step in the exact opposite direction. Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adapter for class with slots
* Wolfgang Schnerring w...@gocept.com [2009-12-07 08:53]:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
I'll try and see whether I can come up with a way for zope.interface to
do the Right Thing(tm) in this situation.
I forgot to mention this here: the edge case has been fixed and released
in zope.interface-3.5.3
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Bootstrapping ZCA for Python 3.
* Lennart Regebro lrege...@jarn.com [2009-12-06 21:14]: Time had therefore come to zope.testing. Why zope.testing? Because most components in zope.* uses zc.buildout, and zc.buildouts tests uses zope.testing. But of course we here have a bootstrapping problem, zope.testing of course also uses buildout. When I worked on py3 stuff on the DZUG sprint in September, we broke out of that catch-22 by porting zope.testing first, and running its test using http://pypi.python.org/pypi/discover, patched[1] to pick up tests via the test_suite() methods. That way we could run the tests of zope.testing under py3 without needing zope.testing itself or zc.buildout to do so, so porting zope.testing could be tackled. Our work from then is on the regebro-python3 branch (which might be familiar ;-). I don't quite remember how far we've come. I *think* most of the porting work is done and we were last working on integrating Distribute/2to3 into the setup.py, but got hung up on the Distribute side of things. Wolfgang [1] @@ -54,9 +54,12 @@ if isinstance(obj, type) and issubclass(obj, unittest.TestCase): tests.append(self.loadTestsFromTestCase(obj)) -load_tests = getattr(module, 'load_tests', None) +load_tests = getattr(module, 'test_suite', None) if use_load_tests and load_tests is not None: -return load_tests(self, tests, None) +tests = load_tests() +if not tests: +return lambda x: None +return tests return self.suiteClass(tests) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Adapter for class with slots
* Shane Hathaway sh...@hathawaymix.org [2009-12-03 11:44]:
Wolfgang Schnerring wrote:
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
line 419, in _getAdapterRequired
elif not ISpecification.providedBy(r):
TypeError: 'member_descriptor' object is not callable
It looks to me like a possible bug in zope.interface. Try deleting
_zope_interface_coptimizations.so to hopefully expand that traceback.
Thanks for the hint! This enabled me to step through all of it with pdb,
which turns up zope/interface/declarations.py:1249
def getObjectSpecification(ob):
provides = getattr(ob, '__provides__', None)
if provides is not None:
return provides
[...]
So it seems that __provides__ is part of the zope.interface mechanics,
and if unset that attribute should not exist -- but when using __slots__
it always exists, namely as a 'member_descriptor' object.
I'll try and see whether I can come up with a way for zope.interface to
do the Right Thing(tm) in this situation.
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Adapter for class with slots
Hello,
I've stumbled upon a wrinkly edge case (bug?) in zope.component.
What I was trying to do is register an AbsoluteURL adapter for
lovely.remotetask.processor.ProcessorRequest objects, and since they
don't implement a specific interface, I thought I'd use the class
itself as the required component. But registering the adapter for
* lovely.remotetask.processor.ProcessorRequest fails with a strange
TypeError (see below). The reason is that the class inherits from
zope.publisher.base.BaseRequests which uses __slots__.
The minimal reproduction recipe to see the error is this:
class Slotted(object):
__slots__ = ('__provides__')
zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)
Which will raise
File
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
line 419, in _getAdapterRequired
elif not ISpecification.providedBy(r):
TypeError: 'member_descriptor' object is not callable
Why is this? Can this be made to work? How would I go about
investigating that?
Thanks,
Wolfgang
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
* Martijn Faassen faas...@startifact.com [2009-11-27 12:32]: Are people okay with the proposed semantics? +1, I think making these disappear into the language as much as possible is a Good Thing(tm). Would people be okay with such an upgrade path? Any better ideas? Yes, I'm okay with it. I do think we should take care that the transition period is long enough, so that people have a chance to update their code. (The deprecation warnings proposed elsewhere should help there, I think this is a good use case for them.) Thus, we should not start requiring zope.component 4.0 everywhere immediately (because it's new, great and shiny ;), but rather use 3.9+future when we want to use the new semantics, and only after I don't know, 6 months maybe, start switching over completely. Most importantly, any volunteers? I'm interested, but I'm not sure whether I'll have free resources in the near future. :-/ Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I quite like the simplicity of this spelling, so I want to be sure *why* it must be ruled out. (...or does it, really?) I'm thinking that this... * Martijn Faassen faas...@startifact.com [2009-11-25 22:21]: The last one won't work if we want to maintain backwards compatibility. The second argument is the default. is a valid argument, while this... * Tres Seaver tsea...@palladion.com [2009-11-25 13:34]: You can't use an arbitrary number of positional arguments for the contexts, because we need to support the named / default cases too. is not, as evidenced by... * Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]: IFoo(x, y, default=None, name='something') or am I missing something here? So I'm thinking, there is no technical reason that prevents Thomas' spelling, and I'm wondering, do we really have to preserve backwards compatibility for this case? Wolfgang ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 20:56]:
This seems heavier than needed. Also, if someone extends this,
they're going to get an awful lot of sections that might have names
that conflict with names in their buildout. I do like the fact that
the versions section is reusable. :)
Here's an alternative:
[versions]
zope.foo = 1.2.3
zope.bar = 1.2.3
zope.app.baz = 1.2.3
grok.bar = 1.1.0
thirdparty.dependency = 4.4
[ztk]
projects = zope.foo zope.bar zope.app.baz
also-tested = grok.bar
Yup, that looks much better. As far as I'm concerned, let's use this.
(I'll leave it to Martijn to explain whether/which/why additional
information should be stored in the KGS in computer-readable form.)
I've just updated z3c.recipe.compattest to support exactly this:
[buildout]
parts = ztk-tests
extends = the-file-above
[ztk-tests]
recipe = z3c.recipe.compattest
include = ${ztk:projects} ${ztk:also-tested}
Would you give it a try?
Wolfgang
___
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] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 01:36]: On Tue, Aug 11, 2009 at 5:22 PM, Jim Fultonj...@zope.com wrote: - The versions specified in the controlled-packages.cfg don't seem to be honored except for the package being tested. For example, ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for everything else. Fortunately, it appears I can work around this using a buildout versions section. In playing with this today, I'm inclined to think that it would be simpler to use a list of packages in an option to specify the packages to be tested and used a versions section to specify versions, rather than using a controlled-packages configuration file. This doesn't strike me as simpler to *use* (as I said earlier, I'd much prefer a *single* gesture of use this KGS to set up both the versions and the list of packages to run tests for, and I think it's worth spending effort to get there), but I'm not sure that's what you meant. What makes you prefer two files instead of one? I'm quite willing to either merge the z3c.recipe.kgs into compattest or abandon the latter (or whatever) and to write a buildout extension to pin the versions using a controlled-packages file, but I only want to do that kind of work if we're reasonably certain that this is what we want. Wolfgang ___ 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] IRC discussion about testing
* Jim Fulton j...@zope.com [2009-08-12 11:52]: On Wed, Aug 12, 2009 at 2:31 AM, Wolfgang Schnerringw...@gocept.com wrote: * Jim Fulton j...@zope.com [2009-08-12 01:36]: In playing with this today, I'm inclined to think that it would be simpler to use a list of packages in an option to specify the packages to be tested and used a versions section to specify versions, rather than using a controlled-packages configuration file. This doesn't strike me as simpler to *use* (as I said earlier, I'd much prefer a *single* gesture of use this KGS to set up both the versions and the list of packages to run tests for, and I think it's worth spending effort to get there), but I'm not sure that's what you meant. What makes you prefer two files instead of one? I didn't say anything about 2 files. I said I prefered a parts list in a single option in combination with a standard buildout versions section. Sorry for my misunderstanding. In fact, I'm not hung up about the number of files all that much, but rather I'm searching for a way not to duplicate information. And that seems rather diffcult, since you assert... - We'll need the versions section to consume the KGS. That is, given a KGS, you'll often want to use the versions in other buildouts to limit them to the known good configuration. ...while Martijn said here http://article.gmane.org/gmane.comp.web.zope.devel/21328 that the KGS will need to store more information about each package than a versions section can handle. - The parts section and versions section could be specified in a single file, so the gesture for using them could be pretty simple. This seems to be the best we can do, given the above requirements. If I understand you correctly, that file would then look something like this: [versions] zope.foo = 1.2.3 grok.bar = 1.1.0 thirdparty.dependency = 4.4 [zope.foo] tested = true kgs = ztk develop = http://svn.zope.org/repos/main/zope.foo/branches/1.2 [grok.bar] tested = true develop = http://svn.zope.org/repos/main/grok.bar/trunk [thirdparty.dependency] tested = no z3c.recipe.compattest/kgs would learn to extract all sections from the above where tested=true. And zope.kgs/zope.release could then probably be retired (or am I missing something?). - I think a parts list in an option will be easier to control. For example, you will be able to use the standard buildout option incrementing and decrementating machinery to modify it. I don't understand how a parts list could help here. Wolfgang ___ 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] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-02 18:34]: 2. Some of the tests only pass if run separately, due to test interactions. Presumably, this means that other tests aren't cleaning up after themselves. I think we need a standard automated way to run each package's tests separately. I think some folks are working on that. I've just released z3c.recipe.compattest-0.6, which can now populate the list of packages to run test for from a buildout section, which makes it easy to test against a KGS. So, if you're developing zope.foo, you can set up your buildout.cfg like this: [buildout] develop = . parts = whatever else you need compat extends = http://url/to/kgs/versions.cfg # assuming said versions.cfg uses a section called [versions]: versions = versions [versions] # use development version of our package zope.foo = [compat] recipe = z3c.recipe.compattest and then run bin/test-compat to run the tests of each package in versions against the development version of zope.foo (in a separate process). So this means that if someone modifies a package that is in the KGS, they need to run the KGS tests before checking in. After we reach a consensus on how to do it (I'm in favor of the way outlined above, of course ;-), I'd like to add a step-by-step walkthrough of the day-to-day development of a package somewhere below http://docs.zope.org/zopetoolkit/process/index.html, which would include a description of how to run KGS tests. Regarding the KGS, I have a question: Where is the current KGS and how do we update it? By where is I mean the location of the versions.cfg, by current I mean the trunk, the version currently in development, the version where we probably want to bump the version number of a package as soon as a version is released, and by update I mean that I'd like this operation to involve no manual interaction other than committing the new version number to SVN. Wolfgang ___ 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] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-07 06:01]: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. With z3c.recipe.compattest, to build the list of projects to run tests for you can at the moment: - specify project names to include - specify buildout section names whose keys will be included (and it defaults to the [versions] section for ease of use) - specify regexes to remove entries from the included list So if your [versions] section contains projects you don't want to run tests for, I guess you either need to exclude those explicitly, or not feed this section to compattest in the first place and build up the include list in a different way instead. Could you elaborate what use case you are envisioning here? Wolfgang ___ 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] KGS trunk without failures
* Jim Fulton j...@zope.com [2009-08-07 12:39]: 2009/8/7 Fabio Tranchitella kob...@kobold.it: * 2009-08-07 12:28, Jim Fulton wrote: How to do you specify the projects to be tested? Does every project in versions get tested? If so, how do you specify versions for projects that you don't want to run tests for but do want to fix the version of. In my recipe, it automatically tests all the libraries that are marked as tested=true in the controlled-packages.cfg, Ah cool, so you don't just use the versions section. Wolfgang? My guideline was let's rely on buildout rather than let's use zope.kgs or anything else rather specific. Wolfgang ___ 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] KGS trunk without failures
* Fabio Tranchitella kob...@kobold.it [2009-08-07 11:46]: * 2009-08-07 11:42, Wolfgang Schnerring wrote: http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg IMHO the KGS testing should be done using the controlled-packages.cfg and not versions, because some of the packages in the KGS are marked as not to be tested. If controlled-packages.cfg is to be the authoritative represenation of the KGS (and maybe it should be, since it contains more information than versions.cfg) then I'd probably wish for a buildout recipe that can pin versions based on that data format, because I much prefer less moving parts. In other words, I would very much like a single gesture to tell buildout use this KGS: extends=something-or-other.cfg. The rest should Just Work(tm). - Less compiling. Having to explicitly regenerate versions.cfg feels superfluous - While developing something, you probably want to change the KGS from the official one to a local one, having to remember to change both the versions.cfg and the packages.cfg for the compattests is error prone. Regarding the KGS, I have a question: Where is the current KGS and how do we update it? By where is I mean the location of the versions.cfg, AFAICK, It can be built from zope.release. Right. But it's not publicly accessible. (And uploading to say download.zope.org is restricted to people with access there) But if versions.cfg is not to be the authoritative representation of the KGS then my point here is moot. Wolfgang ___ 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] zope.index 3.5.2 broken
* Andreas Jung li...@zopyx.com [2009-08-03 20:21]: On 03.08.09 20:15, Chris McDonough wrote: On 8/3/09 1:07 PM, Shane Hathaway wrote: Marius Gedminas wrote: On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote: the doctests for zope.index 3.5.2 - as used in Zope 2.12 - fail badly: Python's string hashes return different valuesfor half of all the strings on 64-bit machines. This influences the ordering of dictionary keys and some other things too (such as the sequence of random numbers you get if you use a string as the seed). Is there a buildbot for the zope.* or ZTK packages testing them under Linux 32bit and 64 bit? AFAICS all three buildbots listed on http://docs.zope.org/zopetoolkit/process/tools.html do. Wolfgang ___ 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] List of packages in ZTK
* Wolfgang Schnerring w...@gocept.com [2009-07-23 08:32]: * Christian Theune c...@gocept.com [2009-07-04 13:33]: I took the Zope 3.4 KGS, removed the obvious packages that do not belong to the ZTK out of the list and created a home for the master list that defines which packages belong to the ZTK. http://docs.zope.org/zopetoolkit/about/packages.html The following packages say about themselves that they are deprecated, so I proprose moving them to the deprecated section in the package listing as well (I can do the editing if I get a go): Silence is consent, isn't it? ;-) Commited in r102361. Wolfgang ___ 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: zope.testing/trunk/ when a test module does not define a test_suite, first try to load any unittest.TestCase descendants in it before complaining it does not contain any
* Benji York be...@zope.com [2009-07-24 08:02]: On Fri, Jul 24, 2009 at 2:38 AM, Wolfgang Schnerringw...@wosc.de wrote: Log message for revision 102202: when a test module does not define a test_suite, first try to load any unittest.TestCase descendants in it before complaining it does not contain any tests I'd rather zope.testing support the test discovery protocol recently added to the Python standard library and backported as the discover module (http://pypi.python.org/pypi/discover). When I proposed *this exact same* patch to Christian Theune one year ago(!) he demurred with the comment along the lines of the testrunner is up for refactoring and extensibility with regarding test discovery anyway. One year later, nothing like that has happened AFAICS. I'm quite done waiting, so I finally put this in as a stopgap that removes the annoyance for 80% of the cases I know. I'm glad to hear about that discovery protocol (didn't know about it before), and I'm all for a proper solution (the registration of doctests is another point to think about in this area), but I hope you understand that I prefer a temporary fix (that will be replaced by something proper later on) to *no fix at all*. Wolfgang ___ 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] List of packages in ZTK
* Christian Theune c...@gocept.com [2009-07-04 13:33]: I took the Zope 3.4 KGS, removed the obvious packages that do not belong to the ZTK out of the list and created a home for the master list that defines which packages belong to the ZTK. http://docs.zope.org/zopetoolkit/about/packages.html So, if you see that a package is missing or is classified in the wrong way, then please speak up. The following packages say about themselves that they are deprecated, so I proprose moving them to the deprecated section in the package listing as well (I can do the editing if I get a go): zope.modulealias zope.thread zope.app.annotation zope.app.container zope.app.folder zope.app.layers zope.app.skins zope.app.pluggableauth zope.app.session zope.app.traversing zope.app.workflow zope.app.zapi zope.app.intid zope.app.keyreference Wolfgang ___ 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] How to test changes to ZTK packages?
* Tres Seaver tsea...@palladion.com [2009-06-30 20:41]: Jim Fulton wrote: I should know this, but I don't. What is the recommended way to test changes to core ZTK packages to mitigate the risk that changes affect other packages? Is there a page somewhere with instructions? I tried using using zope.release. Building the trunk of zope.release with Python 2.4 and running the tests gives lots of test import errors and test failures. (Lots of tests want to import z3c.pt.) The tests hang when I try to build and run with Python 2.6. There is a recipe for testing *other* packages which might be affected by changes to the package-under-development: http://pypi.python.org/pypi/z3c.recipe.compattest This recipe was written at the Grok dependency-cleanup sprint in January with exactly the purpose Jim talks about: testing packages against each other to make sure changes in one don't adversely affect the others. I haven't studied zope.release closely yet, but I think testing-wise it does quite a similar thing, namely running tests for a set of packages. The difference is that compattest uses either pinned version from buildout (but doesn't supply its own list of pins), or alternatively trunk checkouts. Also, it seems to be more lightweight than zope.release both in concept and in usage (mostly since it only does one thing, namely running tests, and not other release management stuff like creating tarballs and uploading them etc.), but I'm biased since I'm one of the compattest authors. For the record, the usage is 1. add it to your buildout, minimally like so: [compattest] recipe = z3c.recipe.compattest 2. run bin/compattest 3. there is no step three. ;-) I don't know how to supply the set of dependents to that recipe (something in the buildout config file, I guess). You can specify include and exclude options; the default is to include a list of zope.* packages that we pulled out of thin air at the sprint, it'd probably be better to use the KGS as a default instead -- but that would duplicate even more zope.release functionality. I think it would be useful to standardize on *one* compatibility testing method for the ZTK (and then document it). My instinct would be to separate KGS handling from tarball creation from testing, that is, remove the test-business from zope.release and use the compattest recipe instead. (Alternatively, retire compattest and have zope.release gain the ability to use trunks so it could be used for continuous integration purposes as well -- but that doesn't feel quite right, to be honest) Thoughts? Wolfgang ___ 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] Hg mirror available
Hello, * Sidnei da Silva sidnei.da.si...@gmail.com [2009-06-19 14:26]: On Fri, Jun 19, 2009 at 2:43 AM, Wolfgang Schnerringw...@gocept.com wrote: $ svn log repos/project/trunk/feature.txt r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line merged feature1 r8 | wosc | 2009-06-18 17:11:43 +0200 (Thu, 18 Jun 2009) | 1 line implemented feature1 As you can see, Subversion reports the history of the file that happenened on the branch (in r8). Can you show us your 'svn --version'? I suspect what you're seeing is a result of svn 1.5 merge tracking. I've dug a little deeper, and found that the example I presented is a special case, since 'feature.txt' has been *added* on the branch, and Subversion has indeed always treated the history of copied/added/removed files differently. You're right that in the general case, Subversion is only able to show the whole history (including branches) using the 1.5-mergeinfo support. One can invoke this via 'svn log --use-merge-history': on my example repository, compare the output for project/trunk/foo.txt with and without that switch; without it only shows the merge commit. Hmm. This means that even if conversion tools did something useful with the mergeinfo properties (which right now they don't), it would only solve my specific problem of preserving history for the last 6-12 months or so, since the repository I'm dealing with stems from 2003 or something, meaning Subversion 1.2ish, which did not even *store* the information necessary to recover the history. I guess I'll need to think about this some more (and then move to a different mailing list, as we're getting way off-topic for zope-dev ;-) Thanks for your insights, Wolfgang ___ 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] Hg mirror available
* Sebastien Douche sdou...@gmail.com [2009-06-18 01:34]: This is a first attempt to build an Mercurial mirror : http://hg.zope.mirrors.securactive.org/ How did you convert the repository? I'm asking because I noticed that basically all SVN-DVCS conversion tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py, svn-all-fast-export.cpp) do not convert the history properly, more precisely, history that happened on branches is lost: 1. import /trunk/foo.txt 2. branch /trunk to /branches/mybranch 3. edit /mybranch/foo.txt 4. merge /mybranch to /trunk If you now ask svn for the history of /trunk/foo.txt (say with 'svn log'), you see both steps 3 and 4. After conversion to a DVCS with one of the above mentioned tools, you only see step 4, while step 3 never happened in the DVCS repository. I think that's unacceptable, most importantly because all commit messages that happened on branches are lost that way. Does somebody here know something about this phenomenon, by any chance? Am I missing something? Wolfgang ___ 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] Hg mirror available
Hi there, * Sidnei da Silva sidnei.da.si...@gmail.com [2009-06-18 14:28]: I'm asking because I noticed that basically all SVN-DVCS conversion tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py, svn-all-fast-export.cpp) do not convert the history properly, more precisely, history that happened on branches is lost: Here's some context about this from one of the Bazaar developers, John Arbash Meinel. Hopefully that will solve some of your questions? Thanks for relaying! I'm not really sure what he means by edit and then merge without a commit inbetween. So I'm assuming there is one. Sorry for being overly brief in my description; please find below a sample shell script to set up a Subversion repository with a project containing a trunk and a branch. To reproduce the problem I'm concerned about, do this: $ create-repos.sh repos $ svn log repos/project/trunk/feature.txt r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line merged feature1 r8 | wosc | 2009-06-18 17:11:43 +0200 (Thu, 18 Jun 2009) | 1 line implemented feature1 As you can see, Subversion reports the history of the file that happenened on the branch (in r8). After converting the repository, however... $ bzr init-repo repos-bzr $ cd repos-bzr $ bzr svn-import file://$PWD/../repos $ bzr log repos/project/trunk/feature.txt revno: 3 svn revno: 9 (on /project/trunk) committer: wosc timestamp: Thu 2009-06-18 14:11:46 + message: merged feature1 ... this history is lost. Not only does it not appear in the log output, also when looking at bzr visualize it seems like that branch never existed at all in bzr. (I'm new to bzr, am I missing something here?) Now, what really matters is whether or not *Subversion* recorded 4 correctly, such that it can actually see that it was a merge from 3. My understanding is that before svn 1.5 that isn't possible. My understanding is quite different. ;-) As far as I know, SVN always has recorded the history of a file across copies and merges, and so I'm quite sure this has nothing to do with 1.5-style merge tracking. I won't try to track down a reference on that right now, but I'm currently reading up on SVN's APIs so I expect to find the answer there, anyway. I'm pretty sure SVN represents (4) as not a *merge* but as an indentical commit. As I said, I'm still digging through the SVN APIs, so unfortunately I don't have a concrete answer, but I know positively that this history information is readily available, which you can see by passing --verbose to 'svn log': $ svn log -v -c 9 repos r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line Changed paths: M /project/trunk A /project/trunk/feature.txt (from /project/branches/feature1/feature.txt:8) ^ M /project/trunk/foo.txt merged feature1 Wolfgang ** #!/bin/sh if [ $# -lt 1 ]; then echo 12 Usage: $0 repos-path exit 1 fi set -e mkdir $1 repos=$(cd $1 pwd) rmdir $1 working=$(tempfile) rm $working mkdir $working svnadmin create $repos svn mkdir file://$repos/project -m creating project home svn mkdir file://$repos/project/trunk -m creating trunk svn mkdir file://$repos/project/branches -m creating branches svn mkdir file://$repos/project/tags -m creating tags svn co file://$repos/project/trunk $working cd $working mkdir alpha echo foo foo.txt echo bar alpha/bar.txt svn add foo.txt alpha svn commit -m initial version svn cp file://$repos/project/trunk file://$repos/project/tags/0.1 -m tagging 0.1 svn cp file://$repos/project/trunk file://$repos/project/branches/feature1 -m creating branch 1 svn switch file://$repos/project/branches/feature1 echo qux foo.txt echo feature1 feature.txt svn add feature.txt svn commit -m implemented feature1 svn switch file://$repos/project/trunk svn merge file://$repos/project/branches/feature1 svn commit -m merged feature1 svn rm file://$repos/project/branches/feature1 -m remove branch after merge svn cp file://$repos/project/trunk file://$repos/project/tags/0.2 -m tagging 0.2 svn cp file://$repos/project/trunk file://$repos/project/branches/feature2 -m creating branch 2 svn switch file://$repos/project/branches/feature2 echo feature2 feature.txt svn commit -m implemented feature 2 rm -rf $working ___ 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
Re: [Zope-dev] buildbots
* Sebastien Douche sdou...@gmail.com [2009-06-16 14:15]: Hello, On Tue, Jun 16, 2009 at 08:00, Wolfgang Schnerring w...@gocept.com wrote: http://zope.buildbot.securactive.org/waterfall (the ZTK docs mention only the first two. Why?) Because nobody had this server on the list ;). I've added it now. 8-) What I couldn't quite figure out, however is: what, exactly, do these buildbots test? 1. checkout svn://svn.zope.org/repos/main/zope.release/trunk, Ah. I didn't know about zope.release, I'll need to look at that. Thanks! If not, is there something I could do to help make that come true? I can't make this for all packages on SVN ; so what are the packages that you want? I'll need to look into this further, but could you imagine adding another builder, in addition to linux-kgs34 and linux-kgs35, let's say linux-kgstrunk, if there was something like zope.release that this builder could use? Wolfgang ___ 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] buildbots
Hello, from various clippings of this list and the ZTK docs at http://docs.zope.org/zopetoolkit/process/tools.html I've gathered that there are (at least) three buildbot installations running tests for the Zope Toolkit: http://zope3.pov.lt/buildbot/waterfall http://zope3.afpy.org/buildbot/waterfall http://zope.buildbot.securactive.org/waterfall (the ZTK docs mention only the first two. Why?) This is great! I think that having continuous, automated test runs can be very beneficial for spotting problems quickly (e. g. with interoperability). What I couldn't quite figure out, however is: what, exactly, do these buildbots test? I imagine one very useful scenario (don't know if there are others), and that would be for each package X in the (still to be determined?) list of ZTK packages, take its trunk (whenever that is updated) and the trunks of all packages it depends on (only if those are ZTK packages, of course, else use the according released version), and run X's tests. Is this covered by one of these buildbot installations? If not, is there something I could do to help make that come true? Thanks, Wolfgang -- Wolfgang Schnerring · w...@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] Bug tracking
Hello, I'm trying to understand how we are using the bug tracker. I noticed that on Launchpad right now there are both umbrella projects such as Zope2 and Zope3, and individual projects such as zope.app.form and zope.testing -- but the list of those subprojects is very far from comprehensive. I don't understand this duplication. If I fix a bug in, say, zope.testing, I now have to mark it fixed twice, once for zope.testing and once for Zope3, and I don't see how this gains us any information. Shouldn't we rename Zope3 to Zope Toolkit and then fold the various subprojects into that? (We could still use tags or something like that if we need additional filtering capabilities) Am I missing something here? Wolfgang ___ 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] ZTK scope (was: [Checkins] SVN: zope.app.publisher/trunk/)
Hello, * Stephan Richter srich...@cosmos.phy.tufts.edu [2009-06-09 15:51]: On Tuesday 09 June 2009, Wolfgang Schnerring wrote: To make browsers update their caches of resources immediately when the resource changes, the absolute URLs of resources can now be made to contain a hash of the resource's contents, so it will look like /++noop++12345/@@/myresource instead of /@@/myresource. Mmmh, this looks like a lot of extra code to get behavior that is served better with different tools. Have you looked at z3c.versionedresource and z3c.traverser? Both of those should solve these type of use cases well. Hmm, it looks like z3c.versionedresource requires me to use a non-standard way to retrieve a resource's URL, which is a major requirement for me; and I must confess I'm not sure how z3c.traverser would help me implement this functionality. I do feel that this incident touches upon a quite important point, and that is the scope of the Zope Toolkit. As I understand it, the ZTK wants to provide support for developing web applications. To do that, I think it should provide solutions to common problems in that area. Browser caches and CSS/JS-files IMHO is a common problem that is well within the scope of the ZTK, and so we should have a ready-to-use solution there. But sure, this functionality can be moved outside of zope.app.publisher, since with r100748 Resource uses IAbsoluteURL, which can be customized externally, so I'll back out the change for the time being. Wolfgang ___ 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] Who uses request.getPositionalArguments()?
Hello, I've stumbled over this by accident, but it seems that getPositionalArguments() in zope.publisher.base.BaseRequest always returns an empty value (at least, there are no tests in which it has a non-empty value), and it is also not overridden by any of the request subclasses in zope.publisher. I still haven't quite wrapped my head around the whole publishing machinery, but this strikes me as a little strange, nonetheless. Could somebody enlighten me why this is so? Thanks, Wolfgang ___ 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] Who uses request.getPositionalArguments()?
* Stephan Richter srich...@cosmos.phy.tufts.edu [2009-06-09 10:02]: On Tuesday 09 June 2009, Wolfgang Schnerring wrote: I've stumbled over this by accident, but it seems that getPositionalArguments() in zope.publisher.base.BaseRequest always returns an empty value (at least, there are no tests in which it has a non-empty value), and it is also not overridden by any of the request subclasses in zope.publisher. I think this may be a remnant of Zope 2's version of the publisher. The method should be used in mapply() to provide the correct arguments to the method to be called at the end of traversal, but these days we usually do not implement methods that expect any arguments, in fact the common case is this: class View(BrowserView): def __call__(self): return ... But even the case with arguments def __call__(self, foo, bar): is handled directly by mapply() (which does introspection and then looks in the request for the names it found) -- which made getPositionalArguments seem all the more superfluous to me... Wolfgang ___ 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] release zope.testing?
Hello, I've recently fixed two bugs in zope.testing that I find annoying on an almost daily basis (commandline option -1 doesn't work and readline is broken in pdb). Could someone review the changes on the trunk and cut a release of zope.testing? Thanks, Wolfgang ___ 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] zc.recipe.cmmi shared builds
* Fred Drake fdr...@gmail.com [2009-05-16 14:09]: On Tue, May 12, 2009 at 10:56 AM, Wolfgang Schnerring w...@gocept.com wrote: Looks good so far. Could someone do a release of zc.recipe.cmmi (or grant 'wosc' pypi access so I can do it myself)? Done. Thanks! I've just cut the 1.2.0 release that includes the shared build directory functionality. Wolfgang ___ 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] zc.recipe.cmmi shared builds
* Wolfgang Schnerring w...@gocept.com [2009-03-24 16:01]: * Wolfgang Schnerring w...@gocept.com [2009-03-24 10:26]: I'd like to extend zc.recipe.cmmi to support shared build directories. Implemented in r98334. I'll use this locally over the next few days, and will then try to push out a release if it proves stable. Looks good so far. Could someone do a release of zc.recipe.cmmi (or grant 'wosc' pypi access so I can do it myself)? Thanks, Wolfgang ___ 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] zc.recipe.cmmi shared builds
Hello,
I'd like to extend zc.recipe.cmmi to support shared build directories.
Use case example: we use lxml in a lot of our projects, which
currently means having to build libxml and libxslt over and over
again, since the buildout needs to be standalone and thus can't depend
on them being installed on the system. But while that's a necessity
for deployment, it's really annoying for development.
Plan of attack:
Introduce an option shared (defaults to False). If that is set,
a) calculate HASH as a hash of the recipe's current options (e. g.
configure parameters, environment variables)
b) perform the cmmi in ${buildout:download-cache}/cmmi/build/HASH,
if that directory is not present yet. (Probably needs a little thought
about how to differentiate between present and has a complete build
and present but we errored out)
Any thoughts?
Thanks,
Wolfgang
--
Wolfgang Schnerring · w...@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 )
Re: [Zope-dev] zc.recipe.cmmi shared builds
* Wolfgang Schnerring w...@gocept.com [2009-03-24 10:26]: I'd like to extend zc.recipe.cmmi to support shared build directories. Implemented in r98334. I'll use this locally over the next few days, and will then try to push out a release if it proves stable. Wolfgang -- Wolfgang Schnerring · w...@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 )
Re: [Zope-dev] zope.container broken
* Roger Ineichen d...@projekt01.ch [2009-03-09 02:12]: The zope.container package was broken. I added a missing ComponentLookupError import. Also, there was a typo in that conditional branch, it should have been self.context, not just context. I guess that's what I got for not writing a test in the first place when I updated that browserDefault()-method. Sorry... We just (r97680) finally wrote the test and fixed the typo. Wolfgang -- Wolfgang Schnerring · w...@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.publisher uses deprecated IView
Hello, since Dan Korostelev commented on my https://bugs.launchpad.net/zope3/+bug/338136 saying I should take it to the mailing list, here goes: zope.publisher.interfaces.browser.IBrowserView inherits from zope.component.interfaces.IView, which actually is zope.component.bbb.interfaces.IView -- marked as deprecated since 2004, but no pointer what the replacement should be. What's going on here? Wolfgang -- Wolfgang Schnerring · w...@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] zc.selenium Zope2 support
Hello, On http://svn.zope.org/zc.selenium/branches/wosc-zope2/ I've worked to make zc.selenium be usable in Zope2/Five. There are two big changes, apart from having to sprinkle some try/except imports and other small compatibility bits around: 1. Since Zope2 insists quite firmly on running in its own process, the current way reporting of test results to the runner via a thread-shared queue is not possible. Instead, I've integrated a small HTTP serving part into the runner that the browser can POST the results to. This should incur no additional overhead, since the previous way was browser POSTs to zope-side view which puts the results into the queue and now it's browser POSTs to runner-side view which puts the results into the queue. 2. I moved from class-based resources to simply use views (for *), since the Five/Zope2 machinery gave me lots of trouble that just disappeared once I switched to views instead of trying to trick resources into acting like views. I think for zc.selenium-users (who inherit from pytest.Test or use the test:seleniumTest directive) the change should be completely backward-compatible. Could someone please review the branch and check what's missing for it to be merged to the trunk? Thanks, Wolfgang -- Wolfgang Schnerring · w...@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 )
Re: [Zope-dev] z3c.form 2.0
Hello, On Tuesday 10 February 2009, Wolfgang Schnerring wrote: I'd like to introduce this to z3c.form as well (see attached patch). Would it be alright with you for me to commit this to trunk (to then go into the release)? * Stephan Richter srich...@cosmos.phy.tufts.edu [2009-02-11 03:19]: Add a test and you can check it in. :-) Of course. That was a bit sloppy of me ;-), but also I wanted to check first whether there were any objections against the change in general. * Dan Korostelev nad...@gmail.com [2009-02-11 14:21]: Also, please add a note to CHANGES.txt about that you changed the signature of SelectFieldWidget, as it breaks backward-compatibility. Or think a way to avoid that problem. :-) I've put in some parameter munging to retain backwards compatibility. And I've added a changelog entry to describe the feature. ;-) Commited in r96460. Wolfgang -- Wolfgang Schnerring · w...@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 )
Re: [Zope-dev] z3c.form 2.0
* Dan Korostelev nad...@gmail.com [2009-02-09 19:08]:
Source support - Seems to work fine. I've checked that out in my
sandbox instance with zc.sourcefactory's context-less and
context-based sources.
I'd very much like to put in a little bit of flexibility when looking up widgets
for source-based fields: zope.formlib looks up the widget for an IChoice field
by requiring a multi-adapter for (field, field.source) instead of just the
field, thus allowing you to differentiate widgets for different kinds of
sources.
I'd like to introduce this to z3c.form as well (see attached patch). Would it be
alright with you for me to commit this to trunk (to then go into the release)?
Wolfgang
--
Wolfgang Schnerring · w...@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
Index: src/z3c/form/browser/select.py
===
--- src/z3c/form/browser/select.py (revision 96293)
+++ src/z3c/form/browser/select.py (working copy)
@@ -75,7 +75,18 @@
@zope.component.adapter(zope.schema.interfaces.IChoice, interfaces.IFormLayer)
@zope.interface.implementer(interfaces.IFieldWidget)
-def SelectFieldWidget(field, request):
+def ChoiceWidgetDispatcher(field, request):
+Dispatch widget for IChoice based also on its source.
+return zope.component.getMultiAdapter((field, field.vocabulary, request),
+ interfaces.IFieldWidget)
+
+
+# can change to ISource once vocabularies are deprecated
+...@zope.component.adapter(zope.schema.interfaces.IChoice,
+zope.schema.interfaces.IBaseVocabulary,
+interfaces.IFormLayer)
+...@zope.interface.implementer(interfaces.IFieldWidget)
+def SelectFieldWidget(field, source, request):
IFieldWidget factory for SelectWidget.
return FieldWidget(field, SelectWidget(request))
@@ -98,4 +109,4 @@
@zope.interface.implementer(interfaces.IFieldWidget)
def CollectionChoiceSelectFieldWidget(field, value_type, request):
IFieldWidget factory for SelectWidget.
-return SelectFieldWidget(field, request)
+return SelectFieldWidget(field, None, request)
Index: src/z3c/form/browser/select.zcml
===
--- src/z3c/form/browser/select.zcml (revision 96293)
+++ src/z3c/form/browser/select.zcml (working copy)
@@ -11,6 +11,10 @@
/class
adapter
+ factory=.select.ChoiceWidgetDispatcher
+ /
+
+ adapter
factory=.select.SelectFieldWidget
/
Index: src/z3c/form/testing.py
===
--- src/z3c/form/testing.py (revision 96293)
+++ src/z3c/form/testing.py (working copy)
@@ -281,6 +281,7 @@
IPageTemplate, name=interfaces.DISPLAY_MODE)
# Select Widget
+zope.component.provideAdapter(select.ChoiceWidgetDispatcher)
zope.component.provideAdapter(select.SelectFieldWidget)
zope.component.provideAdapter(
widget.WidgetTemplateFactory(getPath('select_input.pt'), 'text/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] zope.app.container -- zope.container
Hello, we are holding a mini sprint at Marijn Faassen's place this week with the main goal of reducing dependencies between Zope packages. One result of this effort is that now the non-ZMI parts of zope.app.container have been factored out into zope.container, and only the ZMI-related bits (zope.app.container.browser) and zope.app.container.interfaces.IAdding remain there. (Martijn Faassen just blogged a visually appealing explanation of why this was a Good Thing(tm) to do.) We did this refactoring in a backwards-compatible way, so all symbols can still be imported from their old location, and there are no deprecation warnings, either, but still -- zope.app.container is deprecated as of now (except of course for the .browser and IAdding parts). We've combed through (most of) svn.zope.org and updated referencing packages accordingly, but if you find something that we've missed (or import from zope.app.container in your own packages), please update it at your convenience. (Christian Theune will be adding import checking functionality to zope.testing's testrunner that can aid in detecting moved imports, this might be helpful for finding such things.) Wolfgang ___ 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 )
