Re: [Zope-dev] [ZODB-Dev] Progress report: porting persistent, BTrees to Python3
On Sun, 2012-12-16 at 22:10 +0100, Godefroid Chapelle wrote: Le 15/12/12 01:52, Tres Seaver a écrit : I fixed the remainig issues in persistent and released 4.0.5 today: its tests properly exercise the C extensions Under Python 3.2 / 3.3. I want to express my thanks to you, Tres, for taking care of that work ! This port of ZODB to Python 3 is really a crucial step for the ZTK ecosystem. After the work already done on zope.interface and zope.component. Further, I'd like to also thank Jim for his work on porting buildout. When this will be finished, porting the rest of the ZTK should be much easier, which hopefully implies that more of us will be able to participate. Hear, hear! - C ___ 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 4 release management
On Thu, 2012-02-02 at 08:46 +0100, Jens Vagelpohl wrote: Hi Chris, For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks sign the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines. I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand). Yes, I remember signing the Repoze repository agreement in a similar way a few years ago. I liked it because it was convenient, sure. But as you say, I doubt it would hold up in a court. IMO, neither would be likely to withstand an extremely well-funded court challenge, because a well-funded legal team could probably convince a judge to disallow distribution of the code for long enough that it would effectively kill the project anyway. - C ___ 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 4 release management
On Wed, 2012-02-01 at 16:29 +0100, Jens Vagelpohl wrote: On Feb 1, 2012, at 15:53 , Charlie Clark wrote: Currently the hurdle to getting involved is signing and sending the committer agreement. A hurdle which I think is worth keeping. For any code released under the Zope Foundation umbrella that hurdle cannot be removed, anyway. To be frank, I don't even think that's a hurdle. And it helps to remind the signer that there are legal requirements and responsibilities involved. For what it's worth, in the Pylons Project, we decided to continue requiring the signing of a contributor's agreement (more or less the same contributor agreement as Zope requires). But instead of signing via paper, we ask that folks sign the contributor agreement by adding their name and date to a CONTRIBUTORS.txt file in a git fork of each repository they wish to commit to (e.g. https://github.com/Pylons/pyramid/blob/master/CONTRIBUTORS.txt). The CONTRIBUTORS.txt *is* the agreement, and the pull request serves as proof that they agree to the contribution terms it outlines. I'm not 100% confident that this will serve as watertight proof of agreement in a well-funded court challenge. But it's a lot easier on the contributor and on the organization. The contributor doesn't need to use a fax or lick a stamp and wait, and at least if they're checked in they're fairly durable and have lots of backups (it would be very impressive if the ZF would be able to produce all the paper contributor agreements that have been signed over the course of Zope's existence on demand). - C ___ 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?
On Sat, 2011-12-17 at 21:57 -0500, Chris McDonough wrote: Hi all, 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? Either way, arguments for or against zope.server would be useful; I'm trying to decide whether to base some new stuff on it. FWIW, just to close this out, I poked and prodded zope.server into a fork named waitress (which only does WSGI). http://pypi.python.org/pypi/waitress The detailed differences between waitress and zope.server are here: http://docs.pylonsproject.org/projects/waitress/en/latest/differences.html I had originally thought I'd backport some of the changes to zope.server, but TBH the changes are pretty fundamental, and would require a ton of work to backport. Instead, if you like the features it provides (and can live with the ones it removes), I'd suggest using waitress instead of zope.server at this point. - C ___ 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 2 WSGI investigation
On Tue, 2012-01-03 at 07:32 +, Martin Aspeli wrote: On 3 January 2012 06:39, Chris McDonough chr...@plope.com wrote: On Mon, 2012-01-02 at 10:39 +, Martin Aspeli wrote: On 2 January 2012 08:50, Wichert Akkerman wich...@wiggy.net wrote: On 01/01/2012 08:39 PM, Martin Aspeli wrote: Hi, There are three known WSGI implementations of the Zope 2 publisher. I've had a look at them and made some notes about what I think provides the best story: ## Zope 2.13 WSGIPublisher Pros: * Allows distributed transaction management with repoze.tm2 * Allows distributed retry with repoze.retry * Ships with Zope * Quite simple Cons: * Requires repoze.tm2 and repoze.rety Why is that a con? I use repoze.tm2 and repoze.retry with all my pyramid projects and they work beautifully. Only insofar as it means you have to have these in your WSGI pipeline or it won't work, so there are more places things can go wrong. You'll note that I also consider not supporting such things a con for infrae.wsgi. I wouldn't get too hung up on it, I was mainly just trying to bring out the differences. It'd be nice if it wasn't a hard requirement, though. FWIW, when I wrote repoze.tm2 I did not know that the transaction module already supported retry, so at least repoze.rety should die in favor of logic in something-like-repoze.tm2 that looks a little more like this: https://github.com/Pylons/pyramid_tm/blob/master/pyramid_tm/__init__.py#L49 (that's obviously not WSGI middleware, I'm just showing what the general logic should look like) Am I right in thinking Pyramid no longer uses repoze.tm2 or a middleware approach? What was the rationale for that design decision? You're right, Pyramid scaffolding no longer supplies repoze.tm2 or any other WSGI middleware component for handling transaction commits/aborts. Instead, it uses a Pyramid tween, which is sort of like internal Pyramid middleware inasmuch as its a user-manageable functional composition terminating at the application. See http://www.slideshare.net/aconrad/alex-conrad-pyramid-tweens-ploneconf-2011 Tweens can be reordeded arbitrarily, and the Pyramid exception handling logic (which locates and executes a Pyramid view when an application exception is raised) is itself a tween. The rationale is that application-specific error logic often needs to be executed after the transaction has been committed or aborted due to an exception. For example, if an exception is raised by an application, you'd like the system to abort the transaction, then potentially display a custom internal server error page (e.g. twitter fail-whale). People want to be able to write the error logic within their existing Pyramid development environment (where they have access to templating systems, a real request object, and possibly their database and other niceties) instead of as WSGI middleware higher in the stack than the transaction manager. The pyramid debug toolbar (the thing that shows the pretty debug pages described at http://docs.pylonsproject.org/projects/pyramid_debugtoolbar/en/latest/) is also a tween, which means it has access to the Pyramid environment that WSGI middleware could not (such as access to the registry, allowing us to display view-configuration information, information about routes, etc). For us, this replaced our use of WebError, much as our use of pyramid_tm replaced our use of repoze.tm2, for mostly the same reasons. FWIW, I believe Tres still disagrees strongly with this decision. - C ___ 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 2 WSGI investigation
On Mon, 2012-01-02 at 10:39 +, Martin Aspeli wrote: On 2 January 2012 08:50, Wichert Akkerman wich...@wiggy.net wrote: On 01/01/2012 08:39 PM, Martin Aspeli wrote: Hi, There are three known WSGI implementations of the Zope 2 publisher. I've had a look at them and made some notes about what I think provides the best story: ## Zope 2.13 WSGIPublisher Pros: * Allows distributed transaction management with repoze.tm2 * Allows distributed retry with repoze.retry * Ships with Zope * Quite simple Cons: * Requires repoze.tm2 and repoze.rety Why is that a con? I use repoze.tm2 and repoze.retry with all my pyramid projects and they work beautifully. Only insofar as it means you have to have these in your WSGI pipeline or it won't work, so there are more places things can go wrong. You'll note that I also consider not supporting such things a con for infrae.wsgi. I wouldn't get too hung up on it, I was mainly just trying to bring out the differences. It'd be nice if it wasn't a hard requirement, though. FWIW, when I wrote repoze.tm2 I did not know that the transaction module already supported retry, so at least repoze.rety should die in favor of logic in something-like-repoze.tm2 that looks a little more like this: https://github.com/Pylons/pyramid_tm/blob/master/pyramid_tm/__init__.py#L49 (that's obviously not WSGI middleware, I'm just showing what the general logic should look like) - C Martin ___ 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 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.server still used?
Hi all, 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? Either way, arguments for or against zope.server would be useful; I'm trying to decide whether to base some new stuff on it. - C ___ 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] zc.buildout 2.0.0a1 for py33...
Could someone copy the existing zc.buildout-2.0.0a1-py3.2.egg file over to zc.buildout-2.0.0a1-py3.3.egg on PyPI so it gets shlepped down when we try to use the Python trunk against existing buildouts? - C ___ 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: 3, OK: 44
On Mon, 2011-12-05 at 23:47 -0500, Chris McDonough wrote: These are both odd doctest failures, perhaps also related to the recent transaction release? Yes. I'll see if I can fix it in the ZODB trunk. The ZODB trunk test that failed has been fixed to work with transaction=1.2.0. The bot that tries to run the ZODB tests under 2.5 will continue to fail. - C ___ 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
On Mon, 2011-12-05 at 15:05 -0500, Chris McDonough wrote: On Mon, 2011-12-05 at 08:07 +0100, Wolfgang Schnerring wrote: * 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. The chrism-dictactions branch was merged to trunk; the changes will be present in zope.configuration 3.8.0 (once released). I've released zope.configuration 3.8.0 with the aforementioned changes. - C ___ 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.sqlalchemy release
On Mon, 2011-12-05 at 16:21 -0500, Chris McDonough wrote: Tomorrow, I plan to: - Merge the chrism-py3 branch of zope.sqlalchemy into its trunk. (http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/) to get Python 3 compatibility. - Once the compat branch is merged, I'll make a 0.7 release of zope.sqlalchemy. Any dissent? I've merged the chrism-py3 branch to trunk and I've made a 0.7 release from the resulting trunk to PyPI. - C ___ 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
On Mon, 2011-12-05 at 08:07 +0100, Wolfgang Schnerring wrote: * 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. The chrism-dictactions branch was merged to trunk; the changes will be present in zope.configuration 3.8.0 (once released). - C ___ 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] transaction pkg release (was Re: zope.sqlalchemy+py3 test failures)
On Sun, 2011-12-04 at 22:12 -0500, Chris McDonough wrote: I'm going to make a new major release of the transaction package tomorrow (without the savepoint release features, and bw incompat with 2.4 and 2.5), unless I hear otherwise. transaction 1.2.0 released with Py3 compat (and removing Py2.4 and Py2.5) compatibility. Tested against the ztk trunk tests under Python 2.6. - C ___ 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.sqlalchemy release
Tomorrow, I plan to: - Merge the chrism-py3 branch of zope.sqlalchemy into its trunk. (http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/) to get Python 3 compatibility. - Once the compat branch is merged, I'll make a 0.7 release of zope.sqlalchemy. Any dissent? - C ___ 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: 3, OK: 44
On Mon, 2011-12-05 at 20:31 -0500, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [1]FAILED winbot / ZODB_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053672.html This appears to be due to the incompatibility of transaction 1.2 with Python 2.6: - -- % --- Getting distribution for 'transaction=1.1.0'. File build\bdist.win32\egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax File c:\eggs\tmpp2qpjq\transaction-1.2.0-py2.5.egg\transaction\tests\savepointsample.py, line 26 class SampleDataManager(object): ^ SyntaxError: invalid syntax - -- % --- This bot configuration needs to be disabled (py 2.5 + ZODB trunk, that is). [2]FAILED winbot / ZODB_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-December/053673.html [3]FAILED winbot / ZODB_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-December/053674.html These are both odd doctest failures, perhaps also related to the recent transaction release? Yes. I'll see if I can fix it in the ZODB trunk. - C ___ 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] merge zope.configuration dictactions branch
ssh://svn.zope.org/repos/main/zope.configuration/branches/chrism-dictactions Rationale: I want to be able to associate a new value (introspectables) with each ZCML configuration action, in support of ZCML support for Pyramid features described at: http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/introspector.html http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/extconfig.html#configuration-introspection A rough example UI for the feature is shown here: http://static.repoze.org/introspection/ 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. A complex system of lengthening and shortening (in zope.configuration.config.resolveConflicts) tries to ensure that the tuple is of the smallest length required by chopping false elements off the end of each action tuple during storage and reconstituting them to 7-element tuples during processing and sorting. I think this juke was purely to make doctests easier to write, but I'm not entirely sure. Up til now, pyramid_zcml could live with actions being at most 7 elements. But recent changes to the Pyramid trunk (adding introspectables) blew out the presumption that an action tuple could be no longer than 7 elements (it now might need to be 8 elements). Rather than extend the structure of the zope.configuration tuple with a Pyramid-only introspectables argument, I've created the chrism-dictactions branch (http://svn.zope.org/zope.configuration/branches/chrism-dictactions/) which changes ZCML action structures to be dictionaries. This allows each action to contain arbitrary keys. This modification satisfies the immediate requirement (adding introspectables) and allows us to never need to change the zope.config code again if more elements need to be added to actions. I could have instead added an extras dictionary on to the end of the tuple as an 8th element, but it seems six of one a half dozen of another, and the z.config code is much easier to understand when the action is just a dictionary instead of a pseudo-struct. All ZTK tests pass with the chrism-dictactions branch, and any code that depended upon the action structures was likely overstepping its bounds anyway. I'd like to merge this branch to the zope.configuration trunk as a result, and create a new release. The (unlikely) alternatives are: drop support for ZCML in Pyramid, drop plans to support introspectables in Pyramid. ___ 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] transaction pkg release (was Re: zope.sqlalchemy+py3 test failures)
On Wed, 2011-10-12 at 06:07 -0400, Chris McDonough wrote: On Sat, 2011-10-01 at 03:28 -0400, Chris McDonough wrote: On Thu, 2011-09-29 at 15:22 +0100, Laurence Rowe wrote: I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Sorry I haven't merged the transaction stuff to trunk yet. While doing a review, I realize that one downside to doing this merge is that it will kill Python 2.4 and 2.5 compatibility. I think this is a reasonable thing, given that Python 2.5 will no longer get any maintenance as of today or so, and Python 2.4 hasn't gotten any for a long time, and folks who need a 2.4/2.5 compat version can always use an older version. That said, before I go ahead and do this merge, is there anyone who believes we should continue to support 2.4 and 2.5 in the transaction package? If so, for how long? Nobody responded to this, so I've merged the chrism-py3 branch into the trunk. Any word on the savepoint release branch featureset before I make a release? I'm going to make a new major release of the transaction package tomorrow (without the savepoint release features, and bw incompat with 2.4 and 2.5), unless I hear otherwise. - C ___ 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.sqlalchemy+py3 test failures.
On Sat, 2011-10-01 at 03:28 -0400, Chris McDonough wrote: On Thu, 2011-09-29 at 15:22 +0100, Laurence Rowe wrote: I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Sorry I haven't merged the transaction stuff to trunk yet. While doing a review, I realize that one downside to doing this merge is that it will kill Python 2.4 and 2.5 compatibility. I think this is a reasonable thing, given that Python 2.5 will no longer get any maintenance as of today or so, and Python 2.4 hasn't gotten any for a long time, and folks who need a 2.4/2.5 compat version can always use an older version. That said, before I go ahead and do this merge, is there anyone who believes we should continue to support 2.4 and 2.5 in the transaction package? If so, for how long? Nobody responded to this, so I've merged the chrism-py3 branch into the trunk. Any word on the savepoint release branch featureset before I make a release? - C ___ 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.schema and Python 3
On Mon, 2011-10-10 at 13:14 +0200, Brian Sutherland wrote: I've managed to port zope.schema to Python 3.2 on a branch (jinty-python3). Woo hoo! It gives up Python 2.5 compatibility and depends on six (http://packages.python.org/six/). Any objections to me merging this branch? Not from me. - C ___ 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.sqlalchemy+py3 test failures.
On Thu, 2011-09-29 at 15:22 +0100, Laurence Rowe wrote: On 29 September 2011 10:33, Chris McDonough chr...@plope.com wrote: On Tue, 2011-09-27 at 12:40 -0400, Tres Seaver wrote: This bootstrap is from Jim's '2' branch of zc.buildout: http://svn.zope.org/zc.buildout/branches/2/bootstrap/bootstrap.py?rev=121484view=auto It is designed to work with Py3k. I've replaced the bootstrap.py in the chrism-py3 branch of both the transaction package and the zope.sqlalchemy packages with that one, and everything looks good! I think we can probably merge both of these branches to their respective trunks and make releases. I have the necessary powers to do it for transaction; I'll try to track down elro to see if he's willing to do it for zope.sqlalchemy. I've added chrism as an owner. Before we make a final release I'd like to revisit the savepoint release branches of transaction / zope.sqlalchemy. I'll bring this up in another mail. Sorry I haven't merged the transaction stuff to trunk yet. While doing a review, I realize that one downside to doing this merge is that it will kill Python 2.4 and 2.5 compatibility. I think this is a reasonable thing, given that Python 2.5 will no longer get any maintenance as of today or so, and Python 2.4 hasn't gotten any for a long time, and folks who need a 2.4/2.5 compat version can always use an older version. That said, before I go ahead and do this merge, is there anyone who believes we should continue to support 2.4 and 2.5 in the transaction package? If so, for how long? - C ___ 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.sqlalchemy+py3 test failures.
On Tue, 2011-09-27 at 12:40 -0400, Tres Seaver wrote: This bootstrap is from Jim's '2' branch of zc.buildout: http://svn.zope.org/zc.buildout/branches/2/bootstrap/bootstrap.py?rev=121484view=auto It is designed to work with Py3k. I've replaced the bootstrap.py in the chrism-py3 branch of both the transaction package and the zope.sqlalchemy packages with that one, and everything looks good! I think we can probably merge both of these branches to their respective trunks and make releases. I have the necessary powers to do it for transaction; I'll try to track down elro to see if he's willing to do it for zope.sqlalchemy. - C ___ 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.sqlalchemy+py3 test failures.
On Mon, 2011-09-26 at 21:47 -0400, Chris McDonough wrote: In case anyone is interested, I've made a stab at porting zope.sqlalchemy to Python 3 at http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/ . Several tests still fail. I could use some help fixing them. To run the test suite: - Create a Python 3.2 virtualenv. - Install nose into the virtualenv. - Check out the chrism-py3 transaction branch from svn://svn.zope.org/repos/main/transaction/branches/chrism-py3 - Install the chrism-py3 transaction checkout into the virtualenv, e.g. $env32/bin/python setup.py develop. - Install this package into the virtualenv eg. run $env32/bin/python setup develop. - Run $env32/bin/python setup.py nosetests. Currently 2 tests fail: Mike Merickel solved this... This is because the setuptools (and nose) testrunners do not respect the ``test_suite`` stanza at the bottom of ``tests.py``; these shouldn't be getting run unless the DSN has postgres in it, and they are getting run regardless (under sqlite). That brings up how to cope with running test suites that depend on zope.testrunner features in a cross-platform way. Currently the bootstrap script in this package wont run under Py3. - C ___ 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.sqlalchemy+py3 test failures.
On Tue, 2011-09-27 at 06:43 +0100, Chris Withers wrote: On 27/09/2011 02:47, Chris McDonough wrote: In case anyone is interested, I've made a stab at porting zope.sqlalchemy to Python 3 at http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/ . Several tests still fail. I could use some help fixing them. Have you tried running the tests by building the buildout instead? (that's making a huge assumption that zc.buildout and zope.testing work on Py3, which I guess isn't the case...) I'm not sure how to do it under Python 3, and I may be sufficiently unmotivated to figure it out without some help. ;-) The tests indeed pass on python 2 using bin/test though, so if I could get the testrunner running the tests under Py3, they would also at this point. - C ___ 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] transaction pkg py3 / doctests
On Sun, 2011-09-25 at 23:10 -0400, Stephan Richter wrote: On Sunday, September 25, 2011, Chris McDonough wrote: Anyway, it all seems to work given those limitations, but I'm having trouble making the doctests pass on Python 3. Are there any doctest ninjas willing to have a look? Looks like you want renormalizers. Unfortunately, they are a zope.testing feature. :-( Any thoughts on how renormalizers and a few other features could be released separately? I just changed the code. All the tests now pass. - C ___ 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.sqlalchemy+py3 test failures.
In case anyone is interested, I've made a stab at porting zope.sqlalchemy to Python 3 at http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/ . Several tests still fail. I could use some help fixing them. To run the test suite: - Create a Python 3.2 virtualenv. - Install nose into the virtualenv. - Check out the chrism-py3 transaction branch from svn://svn.zope.org/repos/main/transaction/branches/chrism-py3 - Install the chrism-py3 transaction checkout into the virtualenv, e.g. $env32/bin/python setup.py develop. - Install this package into the virtualenv eg. run $env32/bin/python setup develop. - Run $env32/bin/python setup.py nosetests. Currently 2 tests fail: [chrism@thinko zope.sqlalchemy]$ env32/bin/python setup.py test running test running egg_info writing requirements to src/zope.sqlalchemy.egg-info/requires.txt writing src/zope.sqlalchemy.egg-info/PKG-INFO writing namespace_packages to src/zope.sqlalchemy.egg-info/namespace_packages.txt writing top-level names to src/zope.sqlalchemy.egg-info/top_level.txt writing dependency_links to src/zope.sqlalchemy.egg-info/dependency_links.txt writing manifest file 'src/zope.sqlalchemy.egg-info/SOURCES.txt' running build_ext testTwoEngines (zope.sqlalchemy.tests.MultipleEngineTests) ... ok testRetry (zope.sqlalchemy.tests.RetryTests) ... ERROR testRetryThread (zope.sqlalchemy.tests.RetryTests) ... ERROR testAbortAfterCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testAbortBeforeCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testBulkDelete (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testBulkUpdate (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testCommit (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testCommitWithSavepoint (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testMarkUnknownSession (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testRelations (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testRollbackAttributes (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testSavepoint (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testSimplePopulation (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testThread (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testTransactionJoining (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok testTwoPhase (zope.sqlalchemy.tests.ZopeSQLAlchemyTests) ... ok == ERROR: testRetry (zope.sqlalchemy.tests.RetryTests) -- Traceback (most recent call last): File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/base.py, line 1633, in _execute_context context) File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/engine/default.py, line 327, in do_execute cursor.execute(statement, parameters) sqlite3.OperationalError: no such table: test_users The above exception was the direct cause of the following exception: Traceback (most recent call last): File /home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/tests.py, line 513, in setUp self.tm1.commit() File /home/chrism/projects/transaction/transaction/_manager.py, line 89, in commit return self.get().commit() File /home/chrism/projects/transaction/transaction/_transaction.py, line 342, in commit reraise(t, v, tb) File /home/chrism/projects/transaction/transaction/compat.py, line 60, in reraise raise value File /home/chrism/projects/transaction/transaction/_transaction.py, line 333, in commit self._commitResources() File /home/chrism/projects/transaction/transaction/_transaction.py, line 473, in _commitResources reraise(t, v, tb) File /home/chrism/projects/transaction/transaction/compat.py, line 60, in reraise raise value File /home/chrism/projects/transaction/transaction/_transaction.py, line 445, in _commitResources rm.tpc_begin(self) File /home/chrism/projects/zope.sqlalchemy/src/zope/sqlalchemy/datamanager.py, line 87, in tpc_begin self.session.flush() File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py, line 1493, in flush self._flush(objects) File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/session.py, line 1562, in _flush flush_context.execute() File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py, line 327, in execute rec.execute(self) File /home/chrism/projects/zope.sqlalchemy/env32/lib/python3.2/site-packages/SQLAlchemy-0.7.2-py3.2.egg/sqlalchemy/orm/unitofwork.py, line 471, in execute uow File
[Zope-dev] transaction pkg py3 / doctests
Hi all,
I've ported the transaction package to Python 3 here:
http://svn.zope.org/transaction/branches/chrism-py3/
To get Python 3 support, it ditches 2.4 and 2.5 support, although I may
try to readd 2.5 support.
Anyway, it all seems to work given those limitations, but I'm having
trouble making the doctests pass on Python 3. Are there any doctest
ninjas willing to have a look?
Here's how to see the failure output (I've also appended them below):
svn co svn+ssh://svn.zope.org/repos/main/transaction/branches/chrism-py3
cd chrism-py3
virtualenv3.2 --no-site-packages env32
env32/bin/python setup.py develop
env32/bin/python setup.py test
- C
Doctest output below:
[chrism@thinko transaction]$ env32/bin/python setup.py test -q
running test
running egg_info
writing requirements to transaction.egg-info/requires.txt
writing transaction.egg-info/PKG-INFO
writing top-level names to transaction.egg-info/top_level.txt
writing dependency_links to transaction.egg-info/dependency_links.txt
writing entry points to transaction.egg-info/entry_points.txt
writing manifest file 'transaction.egg-info/SOURCES.txt'
running build_ext
Failed to abort resource manager: BasicJar 2FC0090 ('abort',)
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 506, in abort
rm.abort(self)
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
318, in abort
self.check('abort')
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
313, in check
raise TestTxnException(error %s % method)
transaction.tests.test_transaction.TestTxnException: error abort
..Error in tpc_abort() on manager BasicJar 3097E50 ('tpc_abort',
'tpc_vote')
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 449, in _commitResources
rm.tpc_vote(self)
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
330, in tpc_vote
self.check('tpc_vote')
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
313, in check
raise TestTxnException(error %s % method)
transaction.tests.test_transaction.TestTxnException: error tpc_vote
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 487, in _cleanup
rm.tpc_abort(self)
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
334, in tpc_abort
self.check('tpc_abort')
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
313, in check
raise TestTxnException(error %s % method)
transaction.tests.test_transaction.TestTxnException: error tpc_abort
F.Error in tpc_abort() on manager
transaction.tests.test_transaction.FailingDataManager object at
0x317abd0
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 444, in _commitResources
rm.tpc_begin(self)
File doctest
transaction.tests.test_transaction.test_addAfterCommitHook[29], line
3, in tpc_begin
raise CommitFailure
transaction.tests.test_transaction.CommitFailure
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 487, in _cleanup
rm.tpc_abort(self)
AttributeError: 'FailingDataManager' object has no attribute 'tpc_abort'
Error in after commit hook exec in function hookRaise at 0x3178d10
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 419, in _callAfterCommitHooks
hook(status, *args, **kws)
File doctest
transaction.tests.test_transaction.test_addAfterCommitHook[52], line
2, in hookRaise
raise TypeError(Fake raise)
TypeError: Fake raise
FError in tpc_abort() on manager
transaction.tests.test_transaction.FailingDataManager object at
0x31832d0
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 444, in _commitResources
rm.tpc_begin(self)
File doctest
transaction.tests.test_transaction.test_addBeforeCommitHook[29], line
3, in tpc_begin
raise CommitFailure
transaction.tests.test_transaction.CommitFailure
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 487, in _cleanup
rm.tpc_abort(self)
AttributeError: 'FailingDataManager' object has no attribute 'tpc_abort'
F.Failed to abort resource manager: BasicJar 31833D0 ('abort',)
Traceback (most recent call last):
File /home/chrism/projects/transaction/transaction/_transaction.py,
line 506, in abort
rm.abort(self)
File
/home/chrism/projects/transaction/transaction/tests/test_transaction.py, line
318, in abort
Re: [Zope-dev] transaction pkg py3 / doctests
On Sun, 2011-09-25 at 18:20 -0400, Chris McDonough wrote: Hi all, I've ported the transaction package to Python 3 here: http://svn.zope.org/transaction/branches/chrism-py3/ To get Python 3 support, it ditches 2.4 and 2.5 support, although I may try to readd 2.5 support. Anyway, it all seems to work given those limitations, but I'm having trouble making the doctests pass on Python 3. Are there any doctest ninjas willing to have a look? Here's how to see the failure output (I've also appended them below): Gah I realize now that some of those failures are actually genuine.. I missed them in the output of the test runner because I wasn't using -q before, and they came above ... ok output. Anyway, the ones I actually need help with are the ones failing due to +IGNORE_EXCEPTION_DETAIL apparently not working. - C ___ 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.interface 3.8 win eggs
On Fri, 2011-09-23 at 13:05 -0500, Alan Runyan wrote: please, can someone create 32/64bit eggs for windows I think someone needs to kick the wineggbuilder, or at least diagnose why it's having trouble building eggs for z.i. I'm not sure who's meant to be running it. - C ___ 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] access to create z.i and z.c releases
Hi folks, I've made tags for zope.interface 3.8.0 and zope.component 3.11.0, as described in a recent thread to this list, but I don't have PyPI owner rights to publish them. Can someone add me to the owners list for those packages (my pypi user name is chrism)? - C ___ 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] access to create z.i and z.c releases
On Thu, 2011-09-22 at 10:10 +0200, Hanno Schlichting wrote: On Thu, Sep 22, 2011 at 9:03 AM, Chris McDonough chr...@plope.com wrote: I've made tags for zope.interface 3.8.0 and zope.component 3.11.0, as described in a recent thread to this list, but I don't have PyPI owner rights to publish them. Can someone add me to the owners list for those packages (my pypi user name is chrism)? Added, release away! Eggcellent, they are both now released. - C ___ 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] access to create z.i and z.c releases
On Thu, 2011-09-22 at 05:10 -0400, Chris McDonough wrote: On Thu, 2011-09-22 at 10:10 +0200, Hanno Schlichting wrote: On Thu, Sep 22, 2011 at 9:03 AM, Chris McDonough chr...@plope.com wrote: I've made tags for zope.interface 3.8.0 and zope.component 3.11.0, as described in a recent thread to this list, but I don't have PyPI owner rights to publish them. Can someone add me to the owners list for those packages (my pypi user name is chrism)? Added, release away! Eggcellent, they are both now released. Would someone be kind enough to kick the wineggbuilder? - C ___ 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
On Fri, 2011-09-09 at 00:57 -0400, Chris McDonough wrote: I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named AdapterRegistry already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances. With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package. The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event. zope.registry also currently provides a minor API in the way of an adapts decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__). First cuts of this at: http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentregistry/ http://svn.zope.org/zope.interface/branches/chrism-componentregistry/ I have merged these two branches to their respective trunks: z.i: https://mail.zope.org/pipermail/checkins/2011-September/057121.html z.c: https://mail.zope.org/pipermail/checkins/2011-September/057124.html If no one has issues with this, I will make releases of both within the next few days. - C ___ 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: 17, OK: 30, UNKNOWN: 1
One of these failures was I *think* due to the fact that zope.interface didn't have an extras_require entry for tests. I've added one; we'll see how it goes. - C On Fri, 2011-09-16 at 01:00 +, Zope tests summarizer wrote: This is the summary for test reports received on the zope-tests list between 2011-09-14 00:00:00 UTC and 2011-09-15 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux Bluebream / Python2.7.2 64bit linux [1]UNKNOWN : winbot / ZODB_dev py_270_win32 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit [2]ZTK 1.0 / Python2.6.5 Linux 64bit [3]ZTK 1.0dev / Python2.4.6 Linux 64bit [4]ZTK 1.0dev / Python2.5.5 Linux 64bit [5]ZTK 1.0dev / Python2.6.5 Linux 64bit [6]ZTK 1.1 / Python2.5.5 Linux 64bit [7]ZTK 1.1 / Python2.6.5 Linux 64bit [8]ZTK 1.1 / Python2.7.2 Linux 64bit [9]ZTK 1.1dev / Python2.5.5 Linux 64bit [10] ZTK 1.1dev / Python2.6.5 Linux 64bit [11] ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win64 [12] winbot / zope.pagetemplate_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 [13] winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 [14] winbot / ztk_dev py_254_win32 [15] winbot / ztk_dev py_265_win32 [16] winbot / ztk_dev py_265_win64 [17] winbot / ztk_dev py_270_win32 [18] winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : winbot / ZODB_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049562.html [2]FAILED ZTK 1.0 / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049560.html [3]FAILED ZTK 1.0dev / Python2.4.6 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049575.html [4]FAILED ZTK 1.0dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049577.html [5]FAILED ZTK 1.0dev / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049576.html [6]FAILED ZTK 1.1 / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049558.html [7]FAILED ZTK 1.1 / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049557.html [8]FAILED ZTK 1.1 / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049556.html [9]FAILED ZTK 1.1dev / Python2.5.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049568.html [10] FAILED ZTK 1.1dev / Python2.6.5 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049569.html [11] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-September/049567.html [12] FAILED winbot / zope.pagetemplate_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-September/049566.html [13] FAILED winbot / ztk_10 py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/049596.html [14] FAILED winbot / ztk_dev py_254_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049589.html [15] FAILED winbot / ztk_dev py_265_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049590.html [16] FAILED winbot / ztk_dev py_265_win64 https://mail.zope.org/pipermail/zope-tests/2011-September/049591.html [17] FAILED winbot / ztk_dev py_270_win32 https://mail.zope.org/pipermail/zope-tests/2011-September/049592.html [18] FAILED winbot / ztk_dev py_270_win64
Re: [Zope-dev] ohloh listings
On Sun, 2011-09-11 at 17:50 -0300, Sidnei da Silva wrote: From that same page: Please do not simply delete and re-add the enlistment. In most cases this does not have any effect (our system will recognize the URL and simply re-add the existing broken download), and it will complicate our debugging efforts. I've found it to work in the past despite that warning. On Sat, Sep 10, 2011 at 6:32 PM, Chris McDonough chr...@plope.com wrote: Hanno, Could you delete and readd the failed repository enlistments at https://www.ohloh.net/p/zope/enlistments?page=13 I think these are them: svn://svn.zope.org/repos/main/zope.schema/trunk svn://svn.zope.org/repos/main/zope.security/trunk They're preventing Zope stats on ohloh from getting updated regularly, I think. ___ 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 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] ohloh listings
Hanno, Could you delete and readd the failed repository enlistments at https://www.ohloh.net/p/zope/enlistments?page=13 I think these are them: svn://svn.zope.org/repos/main/zope.schema/trunk svn://svn.zope.org/repos/main/zope.security/trunk They're preventing Zope stats on ohloh from getting updated regularly, I think. ___ 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
On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote: * 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. 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. 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. I don't share this particular goal, except for in a very general yes it would be nice to clean stuff up sort of way. 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. That's appreciated, but blocking the currently proposed division (at least without some alternative code) will have the same effect. - C ___ 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
On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote: * 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? I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named AdapterRegistry already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances. With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package. The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event. zope.registry also currently provides a minor API in the way of an adapts decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__). - C ___ 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
On Thu, 2011-09-08 at 19:03 -0400, Chris McDonough wrote: On Thu, 2011-09-08 at 13:39 +0200, Wolfgang Schnerring wrote: * 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? I mentioned previously that it's not that much of a stretch to put this code into zope.interface because zope.interface.adapter already defines registry-ish stuff that possesses most of the same concepts as a component registry. It has a class named AdapterRegistry already that has a very similar API as a full-on component registry. The full-on component registry really just an API implemented in terms of multiple z.i.adapter.AdapterRegistry instances. With that in mind, and in the interest of moving forward, I'd suggest we just ditch the zope.registry package and move its code into zope.interface. Then there's no renaming to do at all, we can still innovate in the future without necessarily decommissioning a package. As a bonus, we'll have one fewer dependency package. The zope.registry registration machinery sends events when its API is called. It'd be a bit sucky to have z.event as a hard dependency of zope.interface. But it'd be dead easy to change it to only send registration events if zope.event could be imported. I doubt there's anything listening for these events that doesn't also already depend on zope.event. zope.registry also currently provides a minor API in the way of an adapts decorator. This could (and should) be moved back into zope.component; it's actually not used internally by zope.registry now (although some decoy imports would make you think so if you look at zope.registry.__init__). First cuts of this at: http://svn.zope.org/zope.component/branches/chrism-zope.interface-componentregistry/ http://svn.zope.org/zope.interface/branches/chrism-componentregistry/ - C ___ 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
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? 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. This is a bit icky for me. I'd rather have something with fewer dependencies, or at least dependencies I actually use. 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. 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. - C ___ 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.deprecation
On Mon, 2011-09-05 at 09:53 +0200, Hanno Schlichting wrote: On Mon, Sep 5, 2011 at 1:09 AM, Chris McDonough chr...@plope.com wrote: I've given Python 3 support to zope.deprecation at http://svn.zope.org/zope.deprecation/branches/chrism-unittesting/ - Which Python versions is this thing meant to support? I have it functioning under 2.5, 2.6, 2.7 (and 3.2). Do we need it to support 2.4? We no longer need Python 2.4 compatibility for new stuff (only for bugfixes to ZTK 1.0). - I presume the version number after merge should be bumped to 3.5 (it was branched from 3.42dev)? Yes, we treat Python 3 compatibility as a new feature. So this will only go into ZTK trunk. Great. I've merged my branch into the trunk as per the above. Apparently I don't have owner access on the thing on PyPI so I can't make a release. Currently owners of the zope.deprecation package are: J1m, fdrake, menesis. It'd be nice to either get owner/maintainer access or for someone to create a 3.5 release. - C ___ 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.deprecation
On Mon, 2011-09-05 at 15:00 +0300, Gediminas Paulauskas wrote: Great. I've merged my branch into the trunk as per the above. Apparently I don't have owner access on the thing on PyPI so I can't make a release. Currently owners of the zope.deprecation package are: J1m, fdrake, menesis. It'd be nice to either get owner/maintainer access or for someone to create a 3.5 release. I have added chrism to owners. Leaving to you to make the release. Glanced at the changes, looks good to me. Thanks. I've made a 3.5.0 release to PyPI. - C ___ 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.deprecation
Hi all, I've given Python 3 support to zope.deprecation at http://svn.zope.org/zope.deprecation/branches/chrism-unittesting/ Outstanding questions before I merge: - Which Python versions is this thing meant to support? I have it functioning under 2.5, 2.6, 2.7 (and 3.2). Do we need it to support 2.4? - I converted all tests to unit tests and just made the doctests into docs. I don't think anyone will have an issue with this, but if you do, let me know. - I presume the version number after merge should be bumped to 3.5 (it was branched from 3.42dev)? Thanks, - C ___ 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
On Wed, 2011-08-31 at 10:59 +0200, Hanno Schlichting wrote: On Wed, Aug 31, 2011 at 9:17 AM, Wolfgang Schnerring w...@gocept.com wrote: Splitting zope.configuration into core mechanics and ZCML support makes a lot of sense to me. So, +1 from me. +1 here too It turns out that we were using so little of zope.configuration in the Pyramid core that it was much to replace it than it is to port this stuff (and write docs/unittests) so I withdraw this proposal. FTR, apologies, it's a bit lame of me to not help with a zope.configuration Python 3 porting effort and just fork and steal bits of code I need. We do still depend on the entirety of zope.configuration in an add-on package named pyramid_zcml, so if there is call to port that to Python 3, I may revisit this topic. - C ___ 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
On Thu, 2011-09-01 at 09:15 +0200, Wolfgang Schnerring wrote: * 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). The machinery that makes possible the first three of your stripes above wind up in zope.registry in the current plan, aside from convenience global APIs. The fourth is a concept that doesn't really have any code analogue. The last would continue to be provided by zope.component, at least for Zope, which tends to use the global registry and various registries encountered during traversal. 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?) Yes, it gets attached to the request. We also make it available via a threadlocal, but, by default, we don't hook getSiteManager() to make this possible. Instead we just maintain our own threadlocal registry and provide an API that allows people to obtain the registry without having a request in-hand. Using this API is an in case of emergency break glass sort of thing in Pyramid. But in Pyramid the registry is much more
Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component
On Thu, 2011-09-01 at 09:22 -0400, Jim Fulton wrote:
On Thu, Sep 1, 2011 at 4:27 AM, Chris McDonough chr...@plope.com wrote:
...
- zope.testing (for addCleanUp of the global registry in
z.c.globalregistry and other places)
This particular detail should simply be cleaned up by
moving these calls into tests module.
This is in zope.component.globalregistry at module scope:
base = BaseGlobalComponents('base')
try:
from zope.testing.cleanup import addCleanUp
except ImportError:
pass
else:
addCleanUp(lambda: base.__init__('base'))
del addCleanUp
I didn't see that the registration was conditional on the presence of
zope.testing last night, but if I understand the intent correctly, it's
to ensure that importing z.component at all will add a cleanup callback
to zope.testing such that z.testing.cleanUp() will wipe the global
registry state. Lots of existing tests will break if this isn't done,
so I'm not sure that moving it into a place where it isn't executed as a
side effect is feasible?
- C
___
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
On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote: * 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)? 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. 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. 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. 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. - C ___ 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] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages
Rationale Like the previous proposal by Tres Seaver related to zope.component, this is a step that will help port crucial Pyramid dependencies to Python3: https://github.com/Pylons/pyramid/wiki/Python-3-Porting At the end of this year's US PyCon, Lennart Regebro described the zope.configuration porting effort as mostly dependent on the porting of zope.schema (see http://permalink.gmane.org/gmane.comp.web.zope.devel/26373). In the meantime, 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. An Pyramid add-on named pyramid_zcml still has a dependency on zope.component as it provides ZCML analogues of built-in Pyramid configuration directives. We will likely end up eventually helping to port zope.schema to Python 3 as a result. But splitting the zope.configuration package in two parts seems to make sense regardless, as the Pyramid core just doesn't need the extra zope.schema dependency, it just comes along for the ride. 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, now hosted in the Zope SVN repository: http://svn.zope.org/zope.configmachine/trunk Notes on the new package: - The tests in this package are incomplete. I intend to provide full coverage once discussion concludes, as well as some documentation for the package as a standalone entity. - The branch is not yet Python 3 compatible. It's trivial to make it so, once discussion concludes that the configuration/configmachine division is acceptable. - I have made zope.configuration which depends on zope.configmachine in a branch: http://svn.zope.org/zope.configuration/branches/chrism-configmachine This branch leaves BBB imports intact. Proposal I would like to propose the following changes to the ZTK trunk, after test coverage and documentation for zope.configmachine land: - Land 'zope.configmachine' as a full ZTK package, with its own Launchpad artifacts, etc. This step may also involve moving bugs from zope.configuration to zope.configmachine. - Merge the 'chrism-configmachine' branch of zope.configuration to the trunk, and bump its major version accordingly. - Cut releases of both packages. ___ 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
On Thu, 2011-08-25 at 08:50 +0200, Wolfgang Schnerring wrote: 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? I'm -1 on redefining the meaning of zope.component. 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. - C ___ 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] kudos...
On Tue, 2011-08-09 at 11:48 -0400, Zvezdan Petkovic wrote:
On Aug 8, 2011, at 4:44 PM, Chris McDonough wrote:
Kudos to whomever turned the transaction package's transaction manager
into a context manager and was thoughtful enough to provide the attempts
method (which returns a separate context manager, wrapping the txn context
manager, and retries some number of configurable times).
This makes writing code that integrates with a web system that commits
or aborts as easy as:
import transaction
for attempt in transaction.attempts(attempts):
with attempt as t:
response = handler(request)
if t.isDoomed():
t.abort()
if commit_veto is not None:
veto = commit_veto(request, response)
veto and t.abort()
return response
Very nice.
- C
Yes, this is *very* convenient and I like to use it, but beware of the bug
(it's not affecting you above because of the return).
According to the documentation, it's intended as a replacement for:
for i in range(3):
try:
with transaction:
... some something ...
except SomeTransientException:
continue
else:
break
So, presumably,
for attempt in transanction.attempts(retries):
with attempt as tx:
do_something()
should break after the *first* successful commit.
It doesn't. Instead, it commits do_something() ``retries`` times which is
most probably not intended.
Not sure about that; I just return a value if it succeeds. I wouldnt
expect it to know to break out of the loop without a return in there.
I wound up with this, FWIW:
def tm_tween_factory(handler, registry, transaction=transaction):
# transaction parameterized for testing purposes
commit_veto = registry.settings.get('pyramid_tm.commit_veto',
default_commit_veto)
attempts = int(registry.settings.get('pyramid_tm.attempts', 1))
if not commit_veto:
commit_veto = None
else:
commit_veto = resolver.maybe_resolve(commit_veto)
def tm_tween(request):
if 'repoze.tm.active' in request.environ:
# don't handle txn mgmt if repoze.tm is in the WSGI pipeline
return handler(request)
try:
for attempt in transaction.attempts(attempts):
with attempt as t:
# make_body_seekable will copy wsgi.input if
# necessary, otherwise it will rewind the copy
# to position zero
if attempts != 1:
request.make_body_seekable()
response = handler(request)
if t.isDoomed():
raise AbortResponse(response)
if commit_veto is not None:
veto = commit_veto(request, response)
if veto:
raise AbortResponse(response)
return response
except AbortResponse, e:
return e.response
return tm_tween
A little more verbose but still nice.
See https://bugs.launchpad.net/transaction/+bug/724332
The patch attached to the bug report is just a test that proves that behavior
is unexpected and gives a workaround.
The workaround is simple enough and I prefer to use transaction.attempts
convenience rather than the typical try-except code above.
Still, we really should find time to fix this in the transaction manager code
so that it behaves as expected. (Or change the documentation and tests).
Regards,
Zvezdan
___
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 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] kudos...
Kudos to whomever turned the transaction package's transaction manager into a context manager and was thoughtful enough to provide the attempts method (which returns a separate context manager, wrapping the txn context manager, and retries some number of configurable times). This makes writing code that integrates with a web system that commits or aborts as easy as: import transaction for attempt in transaction.attempts(attempts): with attempt as t: response = handler(request) if t.isDoomed(): t.abort() if commit_veto is not None: veto = commit_veto(request, response) veto and t.abort() return response Very nice. - C ___ 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] wineggbuilder?
I'm pondering making a release of zope.i18nmessageid to PyPI. It has C extensions. If I upload the release, does the wineggbuilder still come along and push windows binary eggs up eventually? - C ___ 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] direction
On Sun, 2011-07-03 at 17:44 +0200, Hanno Schlichting wrote: I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now. Well, if I can choose between modern unmaintained code from Mike Bayer and stone-age unmaintained code from Zope, it's still an easy choice ;-) You might want to talk to Wiggy about that. He has a lot of experience with Beaker. And looking at the basics of what Beaker does here, it's still much more useful and of better quality than what we have in Zope 2. If there's any other non-framework-specific session machinery out there, we could use that as well. But I think most other stuff is tied into Django. Our attempt at penance (still framework specific) is here: http://agendaless.com/Members/tseaver/software/faster/faster-0.5.1/README.txt I don't know of any other sessioning libraries. - C ___ 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] direction
On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote: - Continue to remove functionality tailored for TTW development, like SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI - Document and use the WSGI publisher and remove obsoleted functionality like the virtual host monster, error_log, ZServer/medusa, zopectl/zdaemon Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2). - Make the browser id manager, session data manager, temporary storage optional and remove it and request.SESSION from the core, instead we can use something based on Products.BeakerSessionDataManager / collective.beaker if someone has a need for sessions I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now. - C ___ 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] component registry navelgazing
On Mon, 2011-06-13 at 10:08 +0100, Chris Withers wrote: On 12/06/2011 21:48, Chris McDonough wrote: Currently if you ask a registry to singly-adapt an object to an interface, and the object you're trying to adapt implements that interface, here's what happens: from zope.component.registry import Components c = Components() from zope.interface import Interface, implements class IFoo(Interface): pass ... class Foo(object): ... implements(IFoo) ... foo = Foo() c.queryAdapter(IFoo, foo) None Looking back in history: https://mail.zope.org/pipermail/zope-dev/2008-August/032902.html I guess one or other of us has the parameter order wrong, probably me. Much thread ensued: https://mail.zope.org/pipermail/zope-dev/2008-August/thread.html#32902 https://mail.zope.org/pipermail/zope-dev/2008-September/thread.html#33174 Some justification for keeping the status quo from Fred: https://mail.zope.org/pipermail/zope-dev/2008-September/033172.html I stand by my resultant request here: https://mail.zope.org/pipermail/zope-dev/2008-September/033170.html Maybe less people care about ZCA now and so we might actually get sensible changes made. This argument against makes sense to me: https://mail.zope.org/pipermail/zope-dev/2008-August/032908.html So I've added a method to a subclass of zope.component.registry.Components for my own purposes: def queryAdapterOrSelf(self, object, interface, default=None): provides = providedBy(object) if not interface in provides: return self.queryAdapter(object, interface, default=default) return object - C ___ 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] component registry navelgazing
Currently if you ask a registry to singly-adapt an object to an interface, and the object you're trying to adapt implements that interface, here's what happens: from zope.component.registry import Components c = Components() from zope.interface import Interface, implements class IFoo(Interface): pass ... class Foo(object): ... implements(IFoo) ... foo = Foo() c.queryAdapter(IFoo, foo) None In order to get the object itself back from such an adaptation, you need to use the default= argument. c.queryAdapter(IFoo, foo, default=foo) __main__.Foo object at 0x24a3910 This seems slightly inconsistent with the adaptation worldview imposed by getAdapter/queryAdapter. I think it would be more consistent if c.queryAdapter(IFoo, foo) returned foo if foo already implemented IFoo and there was no other more specific adapter registered for the IFoo/foo pair in the registry, no? Let the bikeshedding begin, - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 14:13 -0400, Jim Fulton wrote: On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. I personally don't see the benefit of externalizing default configuration over having defaults be part of the call-site code as per Tres' example. Having the defaults in the code itself makes it much, much easier for people reading the code to understand the garden path. - C ___ 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] Sprints at PyCon
On Sun, 2011-03-13 at 09:13 +0100, Christian Theune wrote: Hi Guys, On 02/10/2011 07:07 AM, Christian Theune wrote: Hi, I'll be at PyCon during the sprints. As promised from the tasks last year, I'd be happy to organize Zope sprinting activity. Who's coming? Who's interested? Any topic suggestions? Sorry for not updating earlier - I was recovering from a sickness. Unfortunately that also means I won't be at PyCon at all, including the sprints. I guess you'll see each other anyway. Can someone take the lead and get everyone who's working on Zope stuff to post a quick update here during the sprints on what's going on? We missed you there... - C Christian ___ 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] my take on ZCML's includeOverrides
I just wanted to point out where we ended up wrt reusing zope.configuration in Pyramid. Pyramid uses zope.configuration internally to provide 2-phase configuration and conflict detection; not just via ZCML but also via imperative Python code. It uses the same included configuration is overridden by more local configuration automated conflict detection strategy as used by Zope. I did not emulate includeOverrides directly for imperative usage. Instead, Pyramid exposes a commit method on it's configurator which allows folks to get slightly more control over conflict behavior. Details are here: http://docs.pylonsproject.org/projects/pyramid/1.0/narr/advconfig.html On Tue, 2010-12-07 at 15:32 -0500, Chris McDonough wrote: On Tue, 2010-12-07 at 14:27 -0500, Chris McDonough wrote: [13:48] mcdonc override is exactly the wrong phrase to use in the name of this directive [13:51] mcdonc what it boils down to is that you never, ever really want to use includeOverrides except in your rootmost zcml file [13:51] mcdonc and probably not even there [13:51] mcdonc because you can get the same effect by typing the directives there by hand Why would you want to type the directives by hand? I *think* I'm of the opinion that libraries (or even reusable applications) probably shouldn't need to use includeOverrides. You might disagree. I'd actually like to hear your take on that, because I'm only about 90% confident about that. ;-) I realize that not every application knows whether it's going to be reused or not, but, even so, it's always an option to cutnpaste the topmost ZCML from that application into a new file and disuse the old one. But if you take for granted the idea that libraries shouldn't use includeOverrides, the place that it is actually potentially useful is in the deployment ZCML file (the topmost ZCML file that includes other ZCML from libraries and other application packages). But in this scenario, I already own the topmost ZCML file, and since it's deployment-specific, there's no sense in breaking out the included stuff into a separate file, because no one else will ever reuse it. It's all deployment-specific policy. So, arguing with myself about that: [14:31] mcdonc so i can see exactly one use case for includeOverrides so far [14:31] mcdonc that's that you have an existing application which doesnt have its zcml nicely factored [14:31] mcdonc and you're afraid (for whatever reason) to just cutpaste it into a new app [14:31] mcdonc and you want to create a new package [14:32] mcdonc that includes the other application's zcml then override bits of it [14:32] mcdonc you could do that by doing [14:32] mcdonc include package=oldapp/ [14:32] mcdonc view ../ [14:32] mcdonc view .. [14:32] mcdonc or you could do [14:32] mcdonc include package=oldapp/ [14:33] mcdonc includeOverrides package=newapp.views filename=configure.zcml/ [14:33] mcdonc either would have exactly the same effect So yes, I see what you were getting at in your last mail. But I think we might be wise to draw some lines around this reuse-of-an-application pattern, at least conventionally. My take on application reuse is this: as soon as you've assumed control of top-level configuration via a newapp overrides package, you've more or less chosen to use oldapp as a library rather than as just-an-application (NB: oldapp and newapp are names I mention above in the example of includeOverride, representing an application that wants to be reused as oldapp and a package created by an overriding user as newapp). This sort of usage is a bit weird, because usually you depend on a plain-old-Python library to have a relatively stable API. But in the application-reuse example, often the original oldapp author has provided no such stability assurances with respect to how he uses ZCML. In such a case, you're always going to be depending on implementation details. When you punt to reusing oldapp's toplevel ZCML, it's because you don't want to track changes to oldapp, but you still want to get the benefit of being able to override some of its policy in newapp. I think this is pretty much impossible in general. Although your newapp overrides *may* continue to work across oldapp updates, if oldapp provided no promise of stability, you'll still need to track its changes. It would be much better if the oldapp author provided instructions about how to best reuse his application as a library. Those instructions probably wouldn't instruct customizers to reuse his top-level example ZCML configuration, but might imply reusing some other ZCML files that include configuration unlikely to need to be overridden. Or he might ship part of oldapp as a true library that has a bit of ZCML in it for reuse by integrators, but distribute another package that represents a deployable configuration of oldapp in a separate package
Re: [Zope-dev] PyPy 1.4.1 and the ZTK
On Wed, 2010-12-22 at 09:43 -0500, Jim Fulton wrote: This makes it possible to start testing some of the ZTK with PyPy. There are challenges of course: certain packages, such as zope.interface, use C extensions and would need to be installed in plain-python mode (if available). It is available. The setup script could, presumably, detect if it is running under PyPy and not even try building extensions. It already does. zope.interface falls back to using its Python implementation if it's installed on a platform that doesn't support C compilation. As does zope.i18nmessageid. The ZODB would definitely be an interesting challenge too. This is something I want. The hardest part of this is coming up with a Python BTree implementation. I'd be willing to work on this at a sprint. FWIW, for our web stuff I've found PyPy to be about 3X as slow as CPython (even allowing for the JIT to warm up). But the elephant dances! - C ___ 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] Stopping weekly meetings, moving towards sprints
Thanks for giving it a shot Christian! I always read the meeting notes, if I didn't participate. - C On Tue, 2010-12-21 at 19:46 +0100, Christian Theune wrote: Hi, during my holidays I evaluated where I spend my time. I feel that the weekly IRC meetings in their current form do not foster more development or get stuff done on the maintenance side of things but keep rather reiterating on the things we feel we should do. As they keep adding more maintenance burden on me (preparation and post-mortem) without having much effect (it seemed there was some steam initially but that dropped substantially) I'll seek ways to contribute my time more efficiently. I had a very enjoyable face to face meeting with Hanno Schlichting and Veit Schiele (of DZUG fame) today in which we figured that we'd like to support creative action within the ZTK next year. We'd like to do so by organizing a sprint each quarter over here in Germany. We're sketching out details on how we want organization to work out over the next weeks so that we find the topics that are interesting to people. Our current goal is to get together during March for 3 days, probably in Berlin. Christian ___ 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] ZCML conflict resolution
I'm trying to decide whether to repurpose the conflict detection in zope.configuration for non-XML configuration. zope.configuration has the following resolveConflicts function, which attempts to resolve action discriminator conflicts. def resolveConflicts(actions): Resolve conflicting actions Given an actions list, identify and try to resolve conflicting actions. Actions conflict if they have the same non-null discriminator. Conflicting actions can be resolved if the include path of one of the actions is a prefix of the includepaths of the other conflicting actions and is unequal to the include paths in the other conflicting actions. ... The code in resolveConflicts indeed matches the docstring description. In the test_simple.py test file, a little more light is shed on conflict resolution: Conflicting actions can be resolved if one of the conflicting actions is from a configuration file that directly or indirectly includes the files containing the other conflicting actions. There's also a test in test_xmlconfig.py that goes into details about includeOverrides and conflict detection. (Note that I don't care about includeOverrides here. I think I understand it, after some wrangling with it.) Unfortunately, the documentation in the code tends to explains the mechanics of conflict resolution, but not the intent. I'll take a guess though: - the rootmost directive that participates in a conflict is meant to win. - if there is more than one rootmost directive that participates in a conflict, the conflict cannot be resolved. Does my summary sound about right? Does anyone have any insight as to why this particular conflict resolution strategy was chosen? I'm really just trying to understand the intent. - C ___ 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] my take on ZCML's includeOverrides
Independent of my previous call for discussion about ZCML conflict resolution, I'm cutting and pasting my side of a discussion about the ZCML includeOverrides directive from an IRC chat, because it may come in useful for folks grappling with its behavior. There's not really any human-consumable docs about it. If I've made any mistakes, please let me know. [13:42] mcdonc so ftr, i've found that ZCML's includeOverrides and include to do (at least on one vector) exactly the opposite of what you might expect them to do [13:42] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc when you use includeOverrides it's as if you typed all the directives in the included file into the file you're including from [13:43] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense [13:48] mcdonc override is exactly the wrong phrase to use in the name of this directive [13:51] mcdonc what it boils down to is that you never, ever really want to use includeOverrides except in your rootmost zcml file [13:51] mcdonc and probably not even there [13:51] mcdonc because you can get the same effect by typing the directives there by hand - C ___ 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] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:08 -0500, Jim Fulton wrote: On Tue, Dec 7, 2010 at 1:57 PM, Chris McDonough chr...@plope.com wrote: Independent of my previous call for discussion about ZCML conflict resolution, I'm cutting and pasting my side of a discussion about the ZCML includeOverrides directive from an IRC chat, because it may come in useful for folks grappling with its behavior. There's not really any human-consumable docs about it. If I've made any mistakes, please let me know. [13:42] mcdonc so ftr, i've found that ZCML's includeOverrides and include to do (at least on one vector) exactly the opposite of what you might expect them to do [13:42] mcdonc includeOverrides is a poor name [13:42] mcdonc what it does is to emulate the behavior of inlining stuff into the file you use it from [13:43] mcdonc when you use includeOverrides it's as if you typed all the directives in the included file into the file you're including from [13:43] mcdonc otoh, include doesnt behave like this [13:44] mcdonc you can actually define the same directive in three files [13:44] mcdonc configure.zcml, one.zcml, and two.zcml [13:44] mcdonc and if you use include from configure.zcml of one and two [13:44] mcdonc there will be no conflict [13:45] mcdonc this is because non-conflicting rootmost directives win [13:45] mcdonc otoh, if you use includeOverrides of one and two from configure.zcml [13:45] mcdonc all three will conflict [13:45] mcdonc because its as if you typed them all in configure.zcml by hand [13:45] mcdonc and that means there are three conflicting rootmost directives [13:46] mcdonc if you mentally substitute inline for includeOverrides it makes a little more sense Maybe. It described the mechanism better, but includeOverrides conveys the intent. shrug Sorry, not a criticism, just a personal observation. I assume I'm not wrong about the behavior I describe above? [13:48] mcdonc override is exactly the wrong phrase to use in the name of this directive [13:51] mcdonc what it boils down to is that you never, ever really want to use includeOverrides except in your rootmost zcml file [13:51] mcdonc and probably not even there [13:51] mcdonc because you can get the same effect by typing the directives there by hand Why would you want to type the directives by hand? I *think* I'm of the opinion that libraries (or even reusable applications) probably shouldn't need to use includeOverrides. You might disagree. I'd actually like to hear your take on that, because I'm only about 90% confident about that. ;-) I realize that not every application knows whether it's going to be reused or not, but, even so, it's always an option to cutnpaste the topmost ZCML from that application into a new file and disuse the old one. But if you take for granted the idea that libraries shouldn't use includeOverrides, the place that it is actually potentially useful is in the deployment ZCML file (the topmost ZCML file that includes other ZCML from libraries and other application packages). But in this scenario, I already own the topmost ZCML file, and since it's deployment-specific, there's no sense in breaking out the included stuff into a separate file, because no one else will ever reuse it. It's all deployment-specific policy. I've used includeOverrides in cases where: 1. I want to use 2 high-level components, one of which customizes the other, or in which 2. I wanted to organize overrides in various ways where I don't want to put everything in a root (or high-level file). Of course, you can sometimes get the same effect in other ways. For example, if one high-level component overrides another, then the overriding component can just include the overridden one. Jim ___ 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] my take on ZCML's includeOverrides
On Tue, 2010-12-07 at 14:27 -0500, Chris McDonough wrote: [13:48] mcdonc override is exactly the wrong phrase to use in the name of this directive [13:51] mcdonc what it boils down to is that you never, ever really want to use includeOverrides except in your rootmost zcml file [13:51] mcdonc and probably not even there [13:51] mcdonc because you can get the same effect by typing the directives there by hand Why would you want to type the directives by hand? I *think* I'm of the opinion that libraries (or even reusable applications) probably shouldn't need to use includeOverrides. You might disagree. I'd actually like to hear your take on that, because I'm only about 90% confident about that. ;-) I realize that not every application knows whether it's going to be reused or not, but, even so, it's always an option to cutnpaste the topmost ZCML from that application into a new file and disuse the old one. But if you take for granted the idea that libraries shouldn't use includeOverrides, the place that it is actually potentially useful is in the deployment ZCML file (the topmost ZCML file that includes other ZCML from libraries and other application packages). But in this scenario, I already own the topmost ZCML file, and since it's deployment-specific, there's no sense in breaking out the included stuff into a separate file, because no one else will ever reuse it. It's all deployment-specific policy. So, arguing with myself about that: [14:31] mcdonc so i can see exactly one use case for includeOverrides so far [14:31] mcdonc that's that you have an existing application which doesnt have its zcml nicely factored [14:31] mcdonc and you're afraid (for whatever reason) to just cutpaste it into a new app [14:31] mcdonc and you want to create a new package [14:32] mcdonc that includes the other application's zcml then override bits of it [14:32] mcdonc you could do that by doing [14:32] mcdonc include package=oldapp/ [14:32] mcdonc view ../ [14:32] mcdonc view .. [14:32] mcdonc or you could do [14:32] mcdonc include package=oldapp/ [14:33] mcdonc includeOverrides package=newapp.views filename=configure.zcml/ [14:33] mcdonc either would have exactly the same effect So yes, I see what you were getting at in your last mail. But I think we might be wise to draw some lines around this reuse-of-an-application pattern, at least conventionally. My take on application reuse is this: as soon as you've assumed control of top-level configuration via a newapp overrides package, you've more or less chosen to use oldapp as a library rather than as just-an-application (NB: oldapp and newapp are names I mention above in the example of includeOverride, representing an application that wants to be reused as oldapp and a package created by an overriding user as newapp). This sort of usage is a bit weird, because usually you depend on a plain-old-Python library to have a relatively stable API. But in the application-reuse example, often the original oldapp author has provided no such stability assurances with respect to how he uses ZCML. In such a case, you're always going to be depending on implementation details. When you punt to reusing oldapp's toplevel ZCML, it's because you don't want to track changes to oldapp, but you still want to get the benefit of being able to override some of its policy in newapp. I think this is pretty much impossible in general. Although your newapp overrides *may* continue to work across oldapp updates, if oldapp provided no promise of stability, you'll still need to track its changes. It would be much better if the oldapp author provided instructions about how to best reuse his application as a library. Those instructions probably wouldn't instruct customizers to reuse his top-level example ZCML configuration, but might imply reusing some other ZCML files that include configuration unlikely to need to be overridden. Or he might ship part of oldapp as a true library that has a bit of ZCML in it for reuse by integrators, but distribute another package that represents a deployable configuration of oldapp in a separate package. Or something. I dunno, hard topic. - C ___ 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.interface memory optimization
On Tue, 2010-11-09 at 01:21 +0200, Marius Gedminas wrote: On Mon, Nov 08, 2010 at 03:35:09PM +0100, Brian Sutherland wrote: I've committed 2 patches to a jinty-mem branch of zope.interface. Together these patches reduce the startup memory use of my ZTK based application by 3%. Is that enough to justify their risk/complexity? https://mail.zope.org/pipermail/checkins/2010-November/052516.html https://mail.zope.org/pipermail/checkins/2010-November/052517.html If no-one replies, I'll assume that 3% is just not enough to be interesting and do nothing;) I'm -1 on it for only 3%. ;-) - C It's so interesting I'm going to ask for even more numbers: how much is that 3% in kilobytes, or objects? Is there any measurable speed impact for application startup or test runs (faster/slower)? Otherwise I'm +1, assuming this doesn't somehow make the code 10% slower. Marius Gedminas ___ 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 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.i18nmessageid 3.5.3 released (windows binaries needed)
I made a new release of zope.i18nmessageid (3.5.3) persuant to a conversation that took place on this list a few weeks ago related to switching back to overriding build_ext to allow the package to work on Jython and other CPython platforms. Would someone be kind enough to build and upload new Windows binaries? Here's the related changelog entries: 3.5.3 (2010-08-10) -- - Made compilation of C extension optional again; 3.5.1 broke this inasmuch as this package become unusable on non-CPython platforms. Making the compilation of the C extension optional again implied removing ``setup.py`` code added in 3.5.1 which made the C extension a setuptools Feature and readding code from 3.5.0 which overrides the distutils ``build_ext`` command. - Move pickle equality tests into a unittest.TestCase test to make it easier to condition the tests on whether the C extension has been compiled. This also makes the tests pass on Jython. ___ 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.i18messageid
Fabio, Within the last few months you committed the following change to zope.i18nmessageid: http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=102497r1=101297r2=102497 The commit message is Fixed the compilation of the C extension with python 2.6: refactored it as a setuptools Feature. Can I ask what problem was being fixed with this commit? It undid work I did in this revision: http://svn.zope.org/zope.i18nmessageid/trunk/setup.py?rev=99669r1=97948r2=99669 I should have left a comment in there: the work was effectively there to support building zope.i18nmessageid on Jython and other platforms like GAE that do not support C extensions at all, even optionally. The package no longer builds on Jython (error: Setup script exited with error: Compiling extensions is not supported on Jython), although to be honest I don't really understand why not. I'm hoping we can find a way to retain whatever fix you were trying to make but still allow the package to build on Jython, but I think I need to understand what problem you were fixing first. - C ___ 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] ZODB Documentation Fundraising
Thanks for organizing this Alan. Hopefully folks will follow your lead and contribute. Agendaless put some money into the pot today. On Thu, 2010-06-24 at 14:19 -0500, Alan Runyan wrote: The blog: http://zodbdocs.blogspot.com/ I am coordinating an effort to have a ZODB book written by one of our Zope clan, Carlos de la Guardia. He has completed a recent book for Packt publishing on Grok. He showed interested in writing a ZODB book if it were under Creative Commons. I have set up a blog and focused on behind-the-scenes coordination required to make the book happen. We are now at a point where: - There is an initial outline of topics to cover. - There is a way to contribute financially on the ZODB Docs Blog (through paypal). - If you can contribute to the book with written material and experience. Let me know. I will make a contributor on the blog and you can post articles. Carlos is more than happy to consolidate/pinch material (and of course give the original author credit) and put it into the final book. One of the thoughts would be to write ZODB mini-howtos/articles on the blog. Some initial ideas: transaction module (datamanagers, aftercommithook, etc), debugging scenarios (how to debug a record being mutated accidentally), conflict resolution (writing your own custom impl, btree bucket splits, etc), concurrency, any benchmarking information you have, relstorage, writing your own persistence format (keas.pbpersist?), or query strategies for ZODB. There is a lot of material to cover in this book. - There are also contribution/funding levels available which correlate to recognition of your donation in the book. That is right. Give money and you go down in history in the documentation *wink* We will have a revised outline of the book by Monday evening from Carlos. If you want to contribute material to the Blog -- let me know. You have a channel to voice your experience. More information is on the blog and will be updated as more progress is made. Again the blog is at, http://zodbdocs.blogspot.com/ -- please sign up and subscribe to the RSS feed. I am open for any feedback. I desperately want to get the larger community support and feedback early as possible. Please feel free to send comments, concerns, criticisms. cheers, alan runyan ___ 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 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: Proposed new style for documenting and testing ZTK packages
On 4/17/10 5:20 PM, Tres Seaver wrote: - Documentation should be written for documentation's sake. The emphasis should be on helping people understand what the software is for and how to use it, *not* on coverage. Amen. - Documentation should be executable. Manuel helps a lot for this. Amen. The Sphinx tools for this are pretty neat, too. Documentation needn't be executable. Documentation should be right. But sometimes documentation is just documentation and automating the checking of its rightness isn't reasonable, especially if making it executable takes the slightest bit of meaning away from it as documentation. Sorry. No free lunch here. - C ___ 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] Stacking zope.component registries
Not sure how a new layer setup and teardown is signaled but assuming you can
hook that, do something like this:
class StackManager(object):
def __init__(self, default=None):
self.stack = []
self.default = default
def push(self, info):
self.stack.append(info)
def pop(self):
if self.stack:
return self.stack.pop()
def get(self):
try:
return self.stack[-1]
except IndexError:
return self.default()
def clear(self):
self.stack[:] = []
from zope.component import getGlobalSiteManager
global_registry = getGlobalSiteManager()
def defaults():
return {'registry':global_registry}
manager = StackManager(default=defaults)
def get_current_registry(context=None):
return manager.get()['registry']
from zope.component import getSiteManager
getSiteManager.sethook(get_current_registry)
Then when a layer is pushed:
from zope.comonent.registry import Components
manager.push({'registry':Components()})
And popped:
manager.pop()
On 4/8/10 1:26 PM, Martin Aspeli wrote:
Hi,
I'd like to come up with a way to set up a test fixture that does the
component registry equivalent of stackable DemoStorage's: whilst a layer
is in effect, calls to provideAdapter() and friends (and ZCML execution)
go into a global registry that is stacked on top of the default global one.
On layer tear-down, the registry is popped, leaving the original (or
previous) global registry intact.
In zope.component.globalregistry, I see:
def provideUtility(component, provides=None, name=u''):
base.registerUtility(component, provides, name, event=False)
base is a module-level variable of type BaseGlobalComponents(). I guess
there'd be a way to use __bases__ to create this kind of stack, but I'm
not clear on the details, and in particular whether this would really
work with provideAdapter() and the rest of the (test-oriented) Python API.
Martin
___
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 )
--
Chris McDonough
Agendaless Consulting, Fredericksburg VA
The repoze.bfg Web Application Framework Book: http://bfg.repoze.org/book
___
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] Stacking zope.component registries
On 4/8/10 4:36 PM, Marius Gedminas wrote: from zope.component import getSiteManager getSiteManager.sethook(get_current_registry) That seems a bit short-sighted: it would break all tests that rely on setSite() working. He said he wanted a global registry, but.. who knows? I stay as far away from that API as possible. ;-) ___ 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.zcml and global registry
On 3/15/10 11:52 AM, Fabio Tranchitella wrote: * 2010-03-08 18:16, Fabio Tranchitella wrote: I'll wait till the week-end to release it, so everybody has the opportunity to have a word on this topic. I've released zope.component 3.9.3 with the change I discussed on the list in the last couple of weeks (ZCML registrations using getSiteManager instead of getGlobalSiteManager) and updated the ztk.conf. Thanks for this work Fabio. - C ___ 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] Stop energy
On 3/3/10 2:06 PM, Fabio Tranchitella wrote:
* 2010-03-03 19:59, Chris McDonough wrote:
I think it would be useful to have a discussion about grouping some Zope
bits along functional lines for marketing purposes. This is really
independent of any discussion about the ZTK.
I wonder if calling zope.{interface,component,schema,configuration,event}
the bicycle repair kit (note the absence of the word zope), with
explicit documentation and a dedicated website really need the approval of
the whole zope3 community.
Probably not. On the other hand, talking about the mechanics of how that might
get done on this maillist seems pretty natural to me. The whole Zope 3
community isn't particularly massive.
Or, better... I don't think anybody can block John Doe to pick up a random
set of packages, give them a name and market them as a framework (or as a
reusable set of libraries) as long as the name zope is not used.
Am I wrong? It's free software, after all.
Why wouldn't that be worked out here? Is it because you just want the
mechanics of such a project done elsewhere without having to see it talked
about on this maillist? Or is it because you disagree that it should be done?
Or... what?
- C
___
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 today's developer meeting
On 3/2/10 1:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. I don't know who people are, and I don't know who they are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional Zope Form Generation package that it would be for them to need to extract such a thing from the ZTK wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named zope.* if they were better organized into functional categories. - C ___ 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 today's developer meeting
On 3/2/10 2:50 PM, Jim Fulton wrote: On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonoughchr...@plope.com wrote: On 3/2/10 1:09 PM, Martijn Faassen wrote: Hi there, Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the Bicycle Toolkit (zope.component, zope.configuration, zope.interface). -1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. I don't know who people are, and I don't know who they are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional Zope Form Generation package that it would be for them to need to extract such a thing from the ZTK wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named zope.* if they were better organized into functional categories. I think you're confusing management and reuse (packaging including dependencies). We all want people to be able to reuse parts of the ZTK. There's broad agreement that we want to clean up dependencies. What's being advocated by many of us is that the ZTK be managed as a whole (for some definition of the whole that shrinks somewhat over time) to allow us to clean things up without causing breakage for people using the ZTK. No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution. You've both successfully beaten any initiative out of me again. Well done. Full speed ahead. - C ___ 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] [ZF] Announcement: 2010 Zope Foundation Board Elections and General Meeting
I nominate Tres Seaver. - C Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (apologies in advance for the cross-post: we need this to reach the whole Zope community). The Zope Foundation board is pleased to announce the regular 2010 general meeting of the foundation will be held on Wednesday, 24 February 2010, at 17:00 UTC. The meeting will be conducted via IRC at the following channel: irc://irc.freenode.net/#zope-foundation Prior to that meeting, the current board will conduct an elections in which foundation members will select seven (7) board members in accordance with the foundation bylaws[1]. Summary - --- - - Nominations open via the foundat...@zope.org mailing list until Friday, 2010-01-29. - - Voting via e-mail to a closed mailing list, from Wednesday, 2010-02-03 through Friday, 2010-02-19. - - Votes tallied by representatives of the current board, using Meek and Warrent STV method using OpenSTV software. - - General meeting and seating of the new board, Wednesday, 2010-02-24. Procedure for Elections - --- The procedure for the elections is as follows: - - Foundation members may nominate any member by responding to the board's announcment on the foundat...@zope.org maling list. Nominations will remain open until Friday, 2010-01-29, 23:00 UTC. - - At the close of the nominations period, the board will create a new mailman list, 'zf-elections-2010', and approve all ZF members to post to the list.. In order to preserve anonymity of votes, foundation members will not be subscribers to the list; access to the list archives will be restricted to the tellers appointed by the board. - - On Wednesday, 2010-02-03, the Secretary will send an e-mail announcing the opening of the voting period. This email will contain the ballot, with careful instructions about how to rank preferences in the reply. The Reply-to header of this e-mail will be set to the 'zf-elections-2010' list. - - ZF members will vote by replying to that e-mail. Voting will remain open until Friday, 2010-02-19, 23:00 UTC. - - At the close of voting, the board will appoint two of its members as tellers. The tellers will use the list archive to tabulate the members' votes, using the OpenSTV application[2] configured to use the Meek and Warren STV method[3]. The tellers will report the election results, along with the raw tallies, at a special board meeting to be held on Tuesday, 2009-02-23, 15:00 UTC. - - After canvassing the results from the tellers, the board will notify all nominees of the success / failure of their candidacy, thanking them for their willingness to serve. - - At the general meeting, the last item on the agenda will the announcement of the election results, including a vote to seat the board. An online version of this announcement is available at: http://foundation.zope.org/news/2010_election_and_general_meeting/ References - -- [1] http://foundation.zope.org/bylaws/zope_foundation_bylaws.pdf [2] http://stv.sourceforge.net/aboutopenstv [3] http://stv.sourceforge.net/votingmethods/meek Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktZ3V8ACgkQ+gerLs4ltQ6sDQCfbV+M85FnxeiSypdy0WBHle1A 7+sAn2aZoP5pb0sqK4ir84d9rhm09HiO =urx1 -END PGP SIGNATURE- ___ foundation mailing list foundat...@zope.org https://mail.zope.org/mailman/listinfo/foundation ___ 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] Where is the position of BlueBream in Zope ecosystem ?
Lennart Regebro wrote: 5. There is also BFG, which doesn't include/build on the ZTK (as the others do). Right, it's loosely coupled with the ZCA, but you can throw that out too, if you like? Chris has to answer that. BFG uses some Zope software, like, say, Pylons uses software made by Ian Bicking. This is about the best way to describe the relationship. The fact that BFG is built on top of the ZCA is an implementation detail. As a consumer of BFG (as a programmer of a BFG application), you aren't going to throw out the ZCA, because a) there'd be no reason to do so, it's an implementation detail that is invisible to you and b) BFG would stop working. In the future, BFG may or may not depend on the set of Zope packages on which it currently depends. It may begin to depend on more Zope packages, or fewer, or disuse all of them entirely. But whatever decisions are made wrt its Zope dependencies, BFG will be largely backwards compatible with itself between releases. - C ___ 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] Where is the position of BlueBream in Zope ecosystem ?
Everything Tres said I agree with. I think it's useful for descriptions of Zope-related frameworks to include BFG and other frameworks that use a small number of Zope technologies. But I think some distinction needs to be made between the ZTK and some Zope packages. In particular, I'm uncomfortable with descriptions of BFG that say it depends on the ZTK because the current formal definition of the ZTK is what's in its buildout include file, or at least its defined by the packages listed at http://docs.zope.org/zopetoolkit/releases/packages-trunk.html. By this definition, BFG isn't (and will never be) a ZTK consumer, because it doesn't use 95% of those packages; however it is very much a bicycle repair kit consumer. So it seems like a good idea to explicitly distinguish the set of packages that BFG uses from the ZTK by giving the bicycle repair toolkit a name and saying that the ZTK depends on that, if only to give another target point in a diagram that includes frameworks that don't use the entire ZTK. ZCA seems good enough to me, although I don't really care what it's called. - C Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hermann Himmelbauer wrote: Thanks for clearing this up. What I don't understand is: Is ZCA now part of the ZTK or not? I had the impression that ZCA is merely a set of libraries inside the ZTK? Who maintains ZCA? Is this the ZTK steering group or somebody else? I used ZCA to refer to the subset of the ZTK used to do the actual component architecture (zope.interface, zope.component, zope.configuration, and dependencies). There is no separately-managed entity called the ZCA: I have also jokingly referred to it in the past as the bicycle seat toolkit. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktYUykACgkQ+gerLs4ltQ5bqQCgoU/fh5G43yKBSyeGqDBRzguI YRkAn04r7eOd3Bt3eLFo+uBlfrMROZ1M =Ln+v -END PGP 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 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] BFG Logo
After messing around in the Gimp, and failing utterly, I am sorry, the answer is no. - C Jan Ulrich Hasecke wrote: Hi, is there a black on white BFG-logo we can use on zope.de? The white on black logo from the website is not suitable. juh DZUG e.V. ___ 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 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] Stepping back as Zope 2 release manager
Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, I would like to inform you that I intent to retreat from the Zope 2 release manager position soon. I have been serving the Zope community in this position for almost seven years and now it is time to move on and hand over the responsibility to some other person. The reasons for stepping down are pretty easy: I am too busy with other things and I would like to shift my focus on other Zope-related projects but I will remain part of the Zope and Plone community. The Zope community has no official process for choosing a new release manager so I assume some volunteer has to speak up or someone may suggest a honorable person of the Zope community for the position. Thanks for the years of hard work, Andreas. - C ___ 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 registration in ZCML provides IUserPreferredCharsets lost ?
Baiju M wrote: On Mon, Jan 11, 2010 at 10:22 AM, Baiju M mba...@zeomega.com wrote: Hi All, There was an adapter registration provides IUserPreferredCharsets. I can see it has moved to zope.i18n.locales with some others here: http://svn.zope.org/zope.app.i18n/trunk/src/zope/app/i18n/configure.zcml?rev=98208r1=95495r2=98208 But, I cannot see it ever reached here ? http://svn.zope.org/zope.i18n/trunk/src/zope/i18n/locales/configure.zcml?rev=75140view=log Can I add it there ? Instead of zope.app.publisher.browser.ModifiableBrowserLanguages, I will use the new location: zope.publisher.browser.ModifiableBrowserLanguages This will make zope.publisher as dependency for zope.i18n, which may not be a good idea. Please suggest me where we will move this ? I don't know exactly where to move this, but making zope.publisher a dep of zope.i18n would be bad. - C ___ 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] new zope.schema and zope.configuration releases
FYI, I just made two new releases: zope.schema 3.6.1 zope.configuration 3.7.1 These releases provide basic compatibility with Jython. - C ___ 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] patterns for using sphinx with the Zope Toolkit?
Benji York wrote:
On Sun, Jan 3, 2010 at 6:43 PM, Chris McDonough chr...@plope.com wrote:
Yeah. I haven't thought about this much, so it might be bollocks, but I
think something like this is what I'm after:
.. code-block-setup::
import sys
from somepackage.testing import DummyModule
sys.modules['models'] = DummyModule()
.. code-block:: python
:linenos:
from models import MyModel
from repoze.bfg.view import bfg_view
from repoze.bfg.chameleon_zpt import render_template_to_response
@bfg_view(name='my_view', request_method='POST', context=MyModel,
permission='read')
def my_view(request):
return {'a':1}
.. code-block-teardown::
del sys.modules['models']
Only the code-block would show up. Actually being a code-block would be
helpful, too, so we could use the other features of code-blocks, like line
numbers. Or something.
If you replace .. code-block-setup:: and .. code-block-teardown::
with .. invisible-code-block:: python you can do that with Manuel now
(http://packages.python.org/manuel/#invisible-code-blocks).
Nice. I'll give that a try.
- C
___
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 Zope 3 name: BlueBream
Strong +1 from me (although my vote is likely not meaningful) Baiju M wrote: Hi All, I am proposing to call Zope 3 - the web frame work as BlueBream. The main use for name is documentation. But the package named bluebream will not provide any part of framework code by itself. All the framework code will be in zope and zope.app namespaces. BTW, the original meaning of BlueBream is same as that of Zope: http://en.wikipedia.org/wiki/Abramis_ballerus Regards, Baiju M ___ 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 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] patterns for using sphinx with the Zope Toolkit?
Lennart Regebro wrote:
On Sun, Jan 3, 2010 at 23:14, Benji York be...@zope.com wrote:
In both of those cases normal doctest blocks seem appropriate.
Not if you don't want the output in the formatting, or if you don't
want the brackets.
Yeah. I haven't thought about this much, so it might be bollocks, but I think
something like this is what I'm after:
.. code-block-setup::
import sys
from somepackage.testing import DummyModule
sys.modules['models'] = DummyModule()
.. code-block:: python
:linenos:
from models import MyModel
from repoze.bfg.view import bfg_view
from repoze.bfg.chameleon_zpt import render_template_to_response
@bfg_view(name='my_view', request_method='POST', context=MyModel,
permission='read')
def my_view(request):
return {'a':1}
.. code-block-teardown::
del sys.modules['models']
Only the code-block would show up. Actually being a code-block would be
helpful, too, so we could use the other features of code-blocks, like line
numbers. Or something.
- C
___
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] patterns for using sphinx with the Zope Toolkit?
Martijn Faassen wrote: Hi there, I am interested in creating sphinx-driven documentation for Zope Toolkit packages. I'd like to maintain the documentation for a package (say, zope.component) in that package, in a 'doc' directory. I'm wondering what experiences people have with maintaining Sphinx docs. I've used plain Sphinx before, but are there any buildout recipes people recommend, for instance? I just use it out of the box after generating some files using sphinx-quickstart. I suspect just changing the resulting Makefile alias from: SPHINXBUILD = sphinx-build To: SPHINXBUILD = ../../../bin/sphinx-build .. or so, for some buildout usage would work just fine. It'd also be interesting to explore using Manuel - how would one add manuel-based testing to a Sphinx documentation tree? I'd like to give the priority to testing documentation samples as opposed to doctest-driven testing. I also want to be careful: sometimes the doctest setup fluff tends to distract from clear documentation, and sometimes the effort in composing doctests will slow down writing documentation. I'd therefore want manuel-tested sample code to be incremental. I want to be able to start out with purely untested sample code and then gradually convert *some* samples over to Manuel. How could we support that pattern? Python samples in Sphinx docs are generated like so: .. code-block:: python a == 1 I did a bit of fooling around with Manuel, because I wanted to make sure that the code blocks in my documentation actually worked, but I wound up in a place where I use Manuel to check only the *syntax* of a subets of the Sphinx code blocks I use. It will do this right out of the box if you read the Manuel docs But I couldn't really figure out a way to do the moral equivalent of this: .. code-block:: python a == 1 .. manuel-expect: True Maybe I missed it. But even so, having Manuel to check even the syntax of code blocks is really useful; I found a couple of errors. Ideas and opinions? This will also help me write the writing Zope Toolkit documentation document. :) - C ___ 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] removing zope.app from the ZTK
I don't think the ZTK as defined by the historical constraints under discussion here has much attraction for a large number of folks who are otherwise willing to put effort into maintaining Zope packages. For these folks, any reduction in number of dependencies and test maintenance is a net win, because they just don't use the stuff they throw out, and they don't have any Grok or legacy Zope3 apps in production to maintain that uses this stuff either. So maybe these folks should come up with their own KGS for whatever they need as a subset of the ZTK. In particular, maybe Zope2 should just be based on this subset. Martijn Faassen wrote: Wichert Akkerman wrote: On 12/29/09 16:25 , Martijn Faassen wrote: Earlier this year we decided to refocus our efforts on the ZTK, a leaner, meaner Zope 3 with a different focus, which has code that we really use, no UI, and with cleaner dependencies. I feel a disconnect here. As I see it the ZTK is not a 'leaner, meaner Zope 3'. Zope 3 is a modular application framework, while the ZTK is a small framework that can be used to build applications or applications frameworks. ZTK has no history since it never existed before (and still is only vapourware since it has no releases nor a release manager), so it does not have any backwards compatibility to worry about. The sense of irony of you feeling a disconnect is rather strong here. I was the one who proposed the ZTK in the first place, remember? It seems that you want to have a 'ZTK+' which aims to be backwards compatible with Zope 3 but is somehow not Zope 3 itself. That is something that not everybody appears to be interested in judging by the lack of progress on Zope 3 itself, but if you want to pursue that I do not see any reason for you not to do that. But it should separate from the ZTK. I'm glad the message of what the ZTK is that I tried to spread so hard has arrived so well. The ZTK wants to reduce responsibilities. One of the responsibilities you gain when you want to reduce responsibilities is to do this responsibly. Regards, Martijn ___ 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 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] small manuel bugfix
Benji York wrote: On Fri, Dec 25, 2009 at 10:31 PM, Chris McDonough chr...@plope.com wrote: Yeah. I'm a fan of unit tests. Yep, me too. To be clear, I do want unit tests in the form of a doctest (like http://svn.zope.org/manuel/trunk/src/manuel/bugs.txt?view=markup). Which may be the best place for this test. I just added tests for the find_code_blocks function to the chrism-codeblock branch in the form of non-doctest unit tests. - C ___ 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] small manuel bugfix
I added a branch of manuel to the Zope SVN that fixes the codeblock plugin when
you use codeblock roles such as:
.. code-block:: python
:linenos:
Currently it only works without roles, e.g.:
.. code-block:: python
The branch is at
svn+ssh://svn.zope.org/repos/main/manuel/branches/chrism-codeblocks
The diff against the current head is as follows:
[chr...@snowpro manuel]$ svn diff
===
--- src/manuel/codeblock.py (.../branches/chrism-codeblocks)
(revision 107071)
+++ src/manuel/codeblock.py (.../trunk) (revision 107071)
@@ -2,9 +2,7 @@
import manuel
import textwrap
-CODEBLOCK_START = re.compile(
-r'(^\.\.\s*(invisible-)?code-block::?\s*python\b(?:\s*\:\w+\:)*)',
-re.MULTILINE)
+CODEBLOCK_START = re.compile(r'^\.\.\s*(invisible-)?code-block::?\s*python\b',
re.MULTILINE)
CODEBLOCK_END = re.compile(r'(\n\Z|\n(?=\S))')
@@ -15,8 +13,7 @@
def find_code_blocks(document):
for region in document.find_regions(CODEBLOCK_START, CODEBLOCK_END):
-start_end = CODEBLOCK_START.search(region.source).end()
-source = textwrap.dedent(region.source[start_end:])
+source = textwrap.dedent('\n'.join(region.source.splitlines()[1:]))
source_location = '%s:%d' % (document.location, region.lineno)
code = compile(source, source_location, 'exec', 0, True)
document.claim_region(region)
I submit it for Benji's consideration.
___
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] small manuel bugfix
Ugh, that patch is rendered backwards... but you get the idea.
Chris McDonough wrote:
I added a branch of manuel to the Zope SVN that fixes the codeblock plugin
when
you use codeblock roles such as:
.. code-block:: python
:linenos:
Currently it only works without roles, e.g.:
.. code-block:: python
The branch is at
svn+ssh://svn.zope.org/repos/main/manuel/branches/chrism-codeblocks
The diff against the current head is as follows:
[chr...@snowpro manuel]$ svn diff
===
--- src/manuel/codeblock.py (.../branches/chrism-codeblocks)
(revision 107071)
+++ src/manuel/codeblock.py (.../trunk) (revision 107071)
@@ -2,9 +2,7 @@
import manuel
import textwrap
-CODEBLOCK_START = re.compile(
-r'(^\.\.\s*(invisible-)?code-block::?\s*python\b(?:\s*\:\w+\:)*)',
-re.MULTILINE)
+CODEBLOCK_START =
re.compile(r'^\.\.\s*(invisible-)?code-block::?\s*python\b',
re.MULTILINE)
CODEBLOCK_END = re.compile(r'(\n\Z|\n(?=\S))')
@@ -15,8 +13,7 @@
def find_code_blocks(document):
for region in document.find_regions(CODEBLOCK_START, CODEBLOCK_END):
-start_end = CODEBLOCK_START.search(region.source).end()
-source = textwrap.dedent(region.source[start_end:])
+source = textwrap.dedent('\n'.join(region.source.splitlines()[1:]))
source_location = '%s:%d' % (document.location, region.lineno)
code = compile(source, source_location, 'exec', 0, True)
document.claim_region(region)
I submit it for Benji's consideration.
___
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 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] small manuel bugfix
Benji York wrote: On Fri, Dec 25, 2009 at 9:37 PM, Chris McDonough chr...@plope.com wrote: I added a branch of manuel to the Zope SVN that fixes the codeblock plugin when you use codeblock roles such as: Looks good. Add tests and I'll merge and release your branch. Sorry about the no-tests thing. :-( I'm not sure what form the tests should take. There's probably no need to reflect this in the documentation, so non-documentation flavored tests are appropriate. Yeah. I'm a fan of unit tests. - C ___ 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
Thomas Lotze wrote: Chris McDonough wrote: Thomas Lotze wrote: Because then, if you use third-party code that uses zope.interface.Interface and other code (third-party or your own) that uses the subclassed interfaces, you'll have to deal with both types at the same time in your client code. You could use the new API on some interfaces but not on others, possibly on the same line of code. How readable or maintainable would such code be? I'm not sure, but if we had it to do all over again, this would be an obvious solution. It would be the work of maybe two days to convert all ZTK packages to use a z.c.interface.Interface, and any existing package would need to be touched anyway to use .adapt and .utility. So it bears some weight I think, even if it is eventually rejected. It does certainly bear some weight as one possibility to be considered. However, my point wasn't so much about converting a limited existing amount of code; you're obviously right about having to touch that anyway in order to use the new methods. My objection is this: If we go to the trouble of implementing basic interfaces in zope.interface plus derived ones with component lookup capabilities in zope.component and keep both around for their respective reasons of existence, then it is expected that there will be code that uses both types of interfaces for these very reasons (and maybe other types which have other added behaviour). Such code would become a lot less maintainable since you'd never know whether a given interface has a particular method just because the one next to it does. OTOH, registering all behaviour an application needs onto the same interface type doesn't create that problem. As long as you're familiar with the application at large, you will know for every interface that occurs in it which methods is has, how they need to be called and what their semantics are. Also, subclassing for adding behaviour introduces the typical problems of hierarchies and tight coupling. This isn't a practical problem as long as we only ever talk about adaptation as the only use of interfaces, but I'm trying to discuss interfaces as a language feature with a greater set of possible use cases. Maybe a hook or API extension just isn't the right thing here. Maybe we just give up on the idea that z.component worldview doesn't belong in z.interface, for the sake of implementation simplicity. - Move the Components class from zope.component.registry to zope.interface.adapter and leave behind an import alias. - Move the base registry from zope.component.globalregistry into zope.interface.adapter and leave behind an import alias. - Move the getSiteManager function from zope.component._api into zope.interface.adapter and leave behind an import alias. - Move the hookable implementation from zope.component.hookable into zope.interface.hookable and leave behind an import alias. - Change the zope.interface.interface.InterfaceClass implementation directly, adding adapts and utility methods, which would use zope.interface.adapter.getSiteManager to find the registry. z.interface would then become responsible for: - Providing an implementation of a component registry which has a z.c worldview: adapters and utilities, stolen from z.c.registry.Components. - Providing a function that returns the current component registry (getSiteManager, which will continue to be hookable; although maybe we should take the opportunity to rename it to actually mean something). - Providing the instance that is the default component registry. All other responsibility (global API functions, a persistent registry implementation, security stuff, zcml support, etc), would remain in z.component. This would also line up conceptually with usage of the ZCA by BFG, which does not hook getSiteManager by default, but still uses a ZCA component registry. - C ___ 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
Chris McDonough wrote: Thomas Lotze wrote: Chris McDonough wrote: Thomas Lotze wrote: Because then, if you use third-party code that uses zope.interface.Interface and other code (third-party or your own) that uses the subclassed interfaces, you'll have to deal with both types at the same time in your client code. You could use the new API on some interfaces but not on others, possibly on the same line of code. How readable or maintainable would such code be? I'm not sure, but if we had it to do all over again, this would be an obvious solution. It would be the work of maybe two days to convert all ZTK packages to use a z.c.interface.Interface, and any existing package would need to be touched anyway to use .adapt and .utility. So it bears some weight I think, even if it is eventually rejected. It does certainly bear some weight as one possibility to be considered. However, my point wasn't so much about converting a limited existing amount of code; you're obviously right about having to touch that anyway in order to use the new methods. My objection is this: If we go to the trouble of implementing basic interfaces in zope.interface plus derived ones with component lookup capabilities in zope.component and keep both around for their respective reasons of existence, then it is expected that there will be code that uses both types of interfaces for these very reasons (and maybe other types which have other added behaviour). Such code would become a lot less maintainable since you'd never know whether a given interface has a particular method just because the one next to it does. OTOH, registering all behaviour an application needs onto the same interface type doesn't create that problem. As long as you're familiar with the application at large, you will know for every interface that occurs in it which methods is has, how they need to be called and what their semantics are. Also, subclassing for adding behaviour introduces the typical problems of hierarchies and tight coupling. This isn't a practical problem as long as we only ever talk about adaptation as the only use of interfaces, but I'm trying to discuss interfaces as a language feature with a greater set of possible use cases. Maybe a hook or API extension just isn't the right thing here. Maybe we just give up on the idea that z.component worldview doesn't belong in z.interface, for the sake of implementation simplicity. - Move the Components class from zope.component.registry to zope.interface.adapter and leave behind an import alias. - Move the base registry from zope.component.globalregistry into zope.interface.adapter and leave behind an import alias. - Move the getSiteManager function from zope.component._api into zope.interface.adapter and leave behind an import alias. - Move the hookable implementation from zope.component.hookable into zope.interface.hookable and leave behind an import alias. - Change the zope.interface.interface.InterfaceClass implementation directly, adding adapts and utility methods, which would use zope.interface.adapter.getSiteManager to find the registry. z.interface would then become responsible for: - Providing an implementation of a component registry which has a z.c worldview: adapters and utilities, stolen from z.c.registry.Components. - Providing a function that returns the current component registry (getSiteManager, which will continue to be hookable; although maybe we should take the opportunity to rename it to actually mean something). - Providing the instance that is the default component registry. All other responsibility (global API functions, a persistent registry implementation, security stuff, zcml support, etc), would remain in z.component. This would also line up conceptually with usage of the ZCA by BFG, which does not hook getSiteManager by default, but still uses a ZCA component registry. - C OK, I just tried this. It's maybe 2 days worth of effort to untangle this as it also effectively means: - Moving the majority of interfaces and exceptions from zope.component.interfaces to zope.interface.interfaces - Folding zope.event into zope.interface (this turns out to make sense when you're down the rabbit hole some of the way). - Untangling the tests. I thought maybe it might be a bit easier (I thought maybe I could get it done today) so I'm going to give up the idea of doing it on spec without some positive feedback about the idea. - C ___ 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] Zope2 and WSGI
Tres Seaver wrote: I set out to fix these bugs in ZPublisher.WSGIPublisher.WSGIResponse, and was dismayed to find it an untested hack-up of the original Publish module, with an untested subclass of HTTPResponse, itself almost completely test-free. So I went down the rabbit hole, and got nearly 100% coverage of HTTPResponse on my branch, along with cleaning out some decade-old fossils. Many thanks... - C ___ 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
Thomas Lotze wrote: Chris McDonough wrote: I'll throw out the obvious... Why not subclass Interface in zope.component and make the required API additions there? If it were anybody but us thinking about doing this, they'd probably just subclass. Because then, if you use third-party code that uses zope.interface.Interface and other code (third-party or your own) that uses the subclassed interfaces, you'll have to deal with both types at the same time in your client code. You could use the new API on some interfaces but not on others, possibly on the same line of code. How readable or maintainable would such code be? I'm not sure, but if we had it to do all over again, this would be an obvious solution. It would be the work of maybe two days to convert all ZTK packages to use a z.c.interface.Interface, and any existing package would need to be touched anyway to use .adapt and .utility. So it bears some weight I think, even if it is eventually rejected. - C ___ 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
I'll throw out the obvious... Why not subclass Interface in zope.component and make the required API additions there? If it were anybody but us thinking about doing this, they'd probably just subclass. - C Martijn Faassen wrote: Wichert Akkerman wrote: [knip] Perhapse LookupError should be a subclass of TypeError. It's a Python built-in. :) Regards, Martijn ___ 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 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 wrote: Chris McDonough wrote: I'll throw out the obvious... Why not subclass Interface in zope.component and make the required API additions there? If it were anybody but us thinking about doing this, they'd probably just subclass. Because then we'd need to rebase all our interfaces to be able to use the new feature, making it pretty useless as a handy shortcut. I guess the counterargument is that you need to change your code anyway to make use of the new feature. So what's the difference? - C ___ 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] Interfaces vs ZCA concepts
I wonder if maybe something like (notionally): class InterfaceBase(object): @classmethod def add_more_api(cls, **kw): cls.__dict__.update(kw) - C Leonardo Rochael Almeida wrote: Funny you should mention this, I've got this idea bugging for a few weeks now, after the last thread: Have the zope.interface package expose a single overridable hook: def getInterfaceAttribute(iface, name, default): This method would be called by any attempt to look up an interface attribute that isn't provided by zope.interface itself. For example: IFoo.adapter(bar, default=baz) Would be the almost the same as: getInterfaceAttribute(IFoo, 'adapter', default=somemarker)(bar, default=baz) That is unless getInterfaceAttribute(IFoo, 'adapter') returned the passed-in marker which would instruct zope.interface to raise an AttributeError instead. In turn, zope.component could then provide a getInterfaceAttribute() implementation that called: getAdapter(IFoo, interface=IInterfaceMethod, name='adapter') Yes, the first parameter above is the original interface. The IInterfaceMethod is an interface defining __call__(*args, **kw) This idea would also allow one to define named adapters for IInterfaceMethod to, for instance, __call__ or __add__, such that the semantics of IFoo(...) or IFoo + IBar could also be changed. Perhaps entry points could be used to provide getInterfaceAttribute implementations, and if multiple entry points are present, each would be called in turn to attempt to provide the attributes of an interface, but maybe this is too much flexibility... Just an idea... Cheers, Leo On Tue, Dec 15, 2009 at 14:16, Thomas Lotze t...@gocept.com wrote: So we've decided to let interfaces grow `adapt` and `utility` methods. I've written a simple and straight-forward implementation of them (see the tlotze-component-API branches of zope.interface and zope.component) that is closely modelled on the exisiting `__call__`. In particular, the new methods use component hooks which are like adapter hooks but with a richer set of call parameters. There are a few tests for the new methods as well, so everything should be fine. Except that I don't like the implications now that I have actually written down the code. I'll describe the problem I see and then suggest an idea that I don't think we've been considering in the discussion two weeks ago: We're intentionally leaking the concept of utilities to zope.interface. Assuming we're entirely fine with this, we still need to decide how much of the particulars of the ZCA we want to bring along: named components, lookup contexts, the ComponentLookupError. My current implementation tries to introduce enough generic behaviour into the `adapt` and `utility` methods so that they don't cause too obvious (conceptual) dependencies of zope.interface on zope.component: * `adapt` and `utility` don't define particular optional arguments but pass all keyword parameters except for `default` to the component hook which, being implemented by zope.component, keeps the knowledge about named adapters and lookup contexts within the latter package. * The hook invokes the `query*` functions to play nice with any other component hooks and the interface methods raise a TypeError if all of them fail to find a component. However, the generic behaviour gets in our way: the method signatures become useless and hooks lose the possibility of raising useful exceptions. I've tried some variations but as long as the `adapt` and `utility` methods are actually implemented by zope.interface, it will always come down to a compromise that either renders the new methods unusable with anything that's not very much like zope.component, or makes for a half-hearted copy of the functionality we currently have in the zope.component API. I discussed this a bit with Wolfgang as we both don't like this kind of compromise in such core functionality. We came up with the idea that a clean solution would be to keep any implementation of the two methods out of zope.interface and rather inject them into the interface API by code kept entirely within zope.component. We do realise how close to the concept of monkey-patching this comes, but maybe it wouldn't be so bad if we could do it in a more structured way (being intentionally vague here yet). In particular, keeping the concrete `adapt` and `utility` methods out of the core implementation of interfaces would address the concern raised by somebody on this list that we were going to tailor zope.interface too much to the needs of the Zope ecosystem. Uses of interfaces other than adaptation and component lookup could get convenience methods registered by the same mechanism zope.component would end up employing, which is a big conceptual advantage from my point of view. What do people think of this? -- Thomas
Re: [Zope-dev] the ZCA API decision
Martijn Faassen wrote: Hi there, I think we've had enough discussion to make a decision. Hopefully everybody is at least reasonably happy with this: An adapt() method will be added to Interface. It takes the objects to adapt as *args, and optional but explicit 'default' and 'name' aguments. A utility() method will be added to Interface. It takes optional but explicit 'default' and 'name' arguments. On the adapter hook (__call__) we will deprecate the implicit second argument for defaults, with a deprecation warning. Instead, we will require people to write out 'default=' explicitly. Otherwise its behavior remains unchanged. I think we can motivate this change purely because IFoo(bar, baz) really is quite surprising compared to IFoo(bar, default=baz). [steering group members, if you are really unhappy with this, please speak up now. Silence is assent. :)] A general +0 from me, because it seems to be 99% bw compat and does no harm. - C ___ 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 )
