Re: [Zope-dev] zc.recipe.testrunner 1.4.0 no longer supports environment option?
On Dec 13, 2010, at 8:00 AM, Michael Howitz wrote: Hi, I have a test section in buildout (version 1.5.2) which uses the environment option to get os.environ configs into the test script. But the environment configuration does not show up in the generated script. The recipe I use is zc.recipe.testrunner 1.4.0 and Python 2.5 (virtualenv). When running the tests of zc.recipe.testrunner with this Python many of them fail including the test for the environment option. Not inherently surprising nor necessarily indicative of a problem in the test suite. Some of the things that the test suite tests are not supported with virtualenv (specifically, the tests for using a system Python). That said, the underlying recipe functionality should work, so the answer to the next question is... Is it intensional that zc.recipe.testrunner does not run when using a virtualenv'ed Python? ...no. I may get a chance to investigate this over the next few weeks, but I'm afraid I can't promise anything. P.S.: The Bugtracker of this project https://bugs.launchpad.net/zc.recipe.testrunner is currently disabled, so I was unable to put this there. I think I registered the project so I could make a branch of it in Launchpad. I'm neither the author nor the maintainer of the package. I'm happy to transfer the Launchpad project to whomever makes sense. Gary ___ 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] zc.recipe.egg bug (tracker)?
On Aug 23, 2010, at 12:36 PM, Andreas Jung wrote:
zc.recipe.egg 1.3.0 fails badly with
While:
Installing supervisor.
Traceback (most recent call last):
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1784, in main
getattr(buildout, command)(args)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 569, in install
installed_files = self[part]._call(recipe.install)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1276, in _call
return f()
File
/Users/ajung/sandboxes/occ/eggs/collective.recipe.supervisor-0.12-py2.6.egg/collective/recipe/supervisor/__init__.py,
line 202, in install
extra_eggs + \
File
/Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.0-py2.6.egg/zc/recipe/egg/egg.py,
line 159, in install
if options.query_bool('dependent-scripts', 'false'):
AttributeError: 'dict' object has no attribute 'query_bool'
Not sure who is in charge and where the related bug tracker is!?
zc.recipe.egg 1.3.0 requires zc.buildout 1.5.0 or higher, as it states it
setup.py. Are you using zc.buildout 1.5.0? If you are, then this is a bug in
zc.recipe.egg (that I don't understand on the face of it; all tests pass, and
Options objects now have a query_bool method).
If you are not forced to use zc.buildout 1.5.0 somehow, I don't know what the
error there is.
Gary
___
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] zc.recipe.egg bug (tracker)?
On Aug 23, 2010, at 1:26 PM, Gary Poster wrote:
On Aug 23, 2010, at 12:36 PM, Andreas Jung wrote:
zc.recipe.egg 1.3.0 fails badly with
While:
Installing supervisor.
Traceback (most recent call last):
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1784, in main
getattr(buildout, command)(args)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 569, in install
installed_files = self[part]._call(recipe.install)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1276, in _call
return f()
File
/Users/ajung/sandboxes/occ/eggs/collective.recipe.supervisor-0.12-py2.6.egg/collective/recipe/supervisor/__init__.py,
line 202, in install
extra_eggs + \
File
/Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.0-py2.6.egg/zc/recipe/egg/egg.py,
line 159, in install
if options.query_bool('dependent-scripts', 'false'):
AttributeError: 'dict' object has no attribute 'query_bool'
Not sure who is in charge and where the related bug tracker is!?
zc.recipe.egg 1.3.0 requires zc.buildout 1.5.0 or higher, as it states it
setup.py. Are you using zc.buildout 1.5.0? If you are, then this is a bug
in zc.recipe.egg (that I don't understand on the face of it; all tests pass,
and Options objects now have a query_bool method).
If you are not forced to use zc.buildout 1.5.0 somehow, I don't know what the
error there is.
Sorry, the traceback shows you are using zc.buildout 1.5.0.
I take it collective.recipe.supervisor does not use an Options object from
zc.buildout? That is what is passed to zc.recipe.egg normally. Options
objects now have a query_bool method, which reduces a lot of duplication of
code acrorss recipes.
I'd argue that this is a bug in the collective.recipe.supervisor, but I knew at
the start that zc.recipe.egg usage was likely to be fragile. I'll put together
a more-backwards-compatible change later, hopefully today.
Gary
___
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] zc.recipe.egg bug (tracker)?
On Aug 23, 2010, at 1:38 PM, Gary Poster wrote:
On Aug 23, 2010, at 1:26 PM, Gary Poster wrote:
On Aug 23, 2010, at 12:36 PM, Andreas Jung wrote:
zc.recipe.egg 1.3.0 fails badly with
While:
Installing supervisor.
Traceback (most recent call last):
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1784, in main
getattr(buildout, command)(args)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 569, in install
installed_files = self[part]._call(recipe.install)
File
/Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py,
line 1276, in _call
return f()
File
/Users/ajung/sandboxes/occ/eggs/collective.recipe.supervisor-0.12-py2.6.egg/collective/recipe/supervisor/__init__.py,
line 202, in install
extra_eggs + \
File
/Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.0-py2.6.egg/zc/recipe/egg/egg.py,
line 159, in install
if options.query_bool('dependent-scripts', 'false'):
AttributeError: 'dict' object has no attribute 'query_bool'
Not sure who is in charge and where the related bug tracker is!?
zc.recipe.egg 1.3.0 requires zc.buildout 1.5.0 or higher, as it states it
setup.py. Are you using zc.buildout 1.5.0? If you are, then this is a bug
in zc.recipe.egg (that I don't understand on the face of it; all tests pass,
and Options objects now have a query_bool method).
If you are not forced to use zc.buildout 1.5.0 somehow, I don't know what
the error there is.
Sorry, the traceback shows you are using zc.buildout 1.5.0.
I take it collective.recipe.supervisor does not use an Options object from
zc.buildout? That is what is passed to zc.recipe.egg normally. Options
objects now have a query_bool method, which reduces a lot of duplication of
code acrorss recipes.
I'd argue that this is a bug in the collective.recipe.supervisor, but I knew
at the start that zc.recipe.egg usage was likely to be fragile. I'll put
together a more-backwards-compatible change later, hopefully today.
1.3.1 has change and is released.
Gary
___
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] zc.recipe.egg bug (tracker)?
On Aug 23, 2010, at 2:53 PM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: 1.3.1 has change and is released. On it's failing in a different way: An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 1784, in main getattr(buildout, command)(args) File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 569, in install installed_files = self[part]._call(recipe.install) File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 1276, in _call return f() File /Users/ajung/sandboxes/occ/eggs/collective.recipe.supervisor-0.12-py2.6.egg/collective/recipe/supervisor/__init__.py, line 202, in install extra_eggs + \ File /Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.1-py2.6.egg/zc/recipe/egg/egg.py, line 173, in install return self._install(reqs, ws, scripts) File /Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.1-py2.6.egg/zc/recipe/egg/egg.py, line 189, in _install options['bin-directory'], File /opt/python-2.6/lib/python2.6/UserDict.py, line 22, in __getitem__ raise KeyError(key) KeyError: 'bin-directory' Please apply this patch to zc.recipe.egg and see if it fixes things for you. Index: src/zc/recipe/egg/egg.py === --- src/zc/recipe/egg/egg.py(revision 115896) +++ src/zc/recipe/egg/egg.py(working copy) @@ -200,6 +200,9 @@ class _BackwardsSupportOption(UserDict.UserDict): +def __init__(self, data): +self.data = data # We want to show mutations to the underlying dict. + def query_bool(self, name, default=None): Given a name, return a boolean value for that name. Gary ___ 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] zc.recipe.egg bug (tracker)?
On Aug 23, 2010, at 3:25 PM, Gary Poster wrote: On Aug 23, 2010, at 2:53 PM, Andreas Jung wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: 1.3.1 has change and is released. On it's failing in a different way: An internal error occurred due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 1784, in main getattr(buildout, command)(args) File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 569, in install installed_files = self[part]._call(recipe.install) File /Users/ajung/sandboxes/occ/eggs/zc.buildout-1.5.0-py2.6.egg/zc/buildout/buildout.py, line 1276, in _call return f() File /Users/ajung/sandboxes/occ/eggs/collective.recipe.supervisor-0.12-py2.6.egg/collective/recipe/supervisor/__init__.py, line 202, in install extra_eggs + \ File /Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.1-py2.6.egg/zc/recipe/egg/egg.py, line 173, in install return self._install(reqs, ws, scripts) File /Users/ajung/sandboxes/occ/eggs/zc.recipe.egg-1.3.1-py2.6.egg/zc/recipe/egg/egg.py, line 189, in _install options['bin-directory'], File /opt/python-2.6/lib/python2.6/UserDict.py, line 22, in __getitem__ raise KeyError(key) KeyError: 'bin-directory' Please apply this patch to zc.recipe.egg and see if it fixes things for you. patch.txt Whether or not it fixed things for you, it was a good fix for the 1.3.1 change. I released it as 1.3.2. Gary ___ 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.traversing's ILocation behavior
On Jul 8, 2010, at 11:04 AM, Martijn Faassen wrote: I propose the following adjustment: try: container = context.__parent__ except AttributeError: container = ILocation(context).__parent__ +1 Gary ___ 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] Circular dependency hell.
On Apr 16, 2010, at 1:35 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: ... So, with that in mind I today went on to zc.buildout, trying to port it to Python 3 by ripping out any usage of zope.testing. Also, the standard development mode for zc.buildout is that you run a dev.py script, that uses zc.buildout to build a buildout for zc.buildout. Obviously, this circularity is the same as I encountered in setuptools, and it's evil. But with zc.buildout it's easy to get rid off at least as I could use setuptools testrunner instead. But then I realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends on zc.buildout. Hohum, another circular depedency. Yup. I don't even know why zc.recipe.egg is broken out from buildout at all. When I was working on my support system Python branches of zc.buildout, I guessed it was because, if it is separate, then using zc.recipe.egg (which follows the standard ``recipe = `` idiom in the .cfg files) uses the same machinery that all the other recipes use. Yes, they are the same package, essentially, which is why zc.recipe.egg is part of the svn checkout of zc.buildout. I followed the same pattern in my branches for the z3c.recipe.scripts recipe. I certainly don't feel strongly about it, but it didn't seem outrageous to me. == Suggestion 2 == Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a dummy package that just points at zc.buildout.recipe.egg (or whatever we decide to call it). That solves that problem. +1 from me. Graphs with cycles are pure evil. I sure which my branches would land first, if they are ever to land. Any changes to buildout are a pain. Big changes are a big pain. Gary ___ 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] Launchpad gardening
On Apr 15, 2010, at 12:51 PM, Sidnei da Silva wrote: On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Thanks Tres and Sidnei, My questions were intended to go to the list anyway. Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit? For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit? Wouldn't it be nice if it was possible? Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch. I didn't think this was true, so I checked another source. :-) bzr does not allow that, actually--at least for bzr branches, and I suspect for svn branches. If the branches are diverged, you can't just push. You need to merge and then push. But, my source for bzr knowledge warns me, if you merge with the public version, and then try to push to the public version, your revno will change, and that will confuse people. So, a better story is to use bzr as if it were svn at that point: bzr co the trunk, bzr merge your changes, and bzr commit. If the Launchpad import of a given SVN package was recently created (since late 2009) then it works quite nicely. If it was made earlier, you will encounter hiccups. With the new imports I've done stuff like this. - bzr branch the import from LP. - Make changes locally and commit. - push branch to LP - make a merge proposal on LP and get a review - bzr push the branch to a new branch on zope's svn (each commit you made locally shows up separately even though it is one big push) - bzr co the svn trunk, merge my changes, and commit. It's quite nice. Handling merges is wildly nicer in the correct dvcs options than svn. The only limitation for bzr right now is that bzr doesn't handle svn externals. That's slated to change this year, I think. If people are curious, Sidnei or I could reach out and get more details of the timeline. Gary ___ 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] Launchpad gardening
On Apr 15, 2010, at 1:27 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Apr 15, 2010, at 12:51 PM, Sidnei da Silva wrote: On Thu, Apr 15, 2010 at 12:41 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Thanks Tres and Sidnei, My questions were intended to go to the list anyway. Can we take a branch from the launchpad mirror and bind it back directly at svn+ssh://svn.zope.org/ to commit? For instance, say I'm reviewing a bugfix proposed by someone that doesn't currently have access to svn.zope.org but added a merge-proposal to lp, can I branch it, bind it to svn+ssh://svn.zope.org and then commit? Wouldn't it be nice if it was possible? Not sure if it would. What you really want to do is to merge the bzr branch you got from Launchpad into the 'trunk' you got from svn.zope.org, which behaves exactly as Tres described on his previous email. Pushing the branch directly without merging first would overwrite the contents of the target branch with the contents of the pushed branch. I didn't think this was true, so I checked another source. :-) bzr does not allow that, actually--at least for bzr branches, and I suspect for svn branches. If the branches are diverged, you can't just push. You need to merge and then push. But, my source for bzr knowledge warns me, if you merge with the public version, and then try to push to the public version, your revno will change, and that will confuse people. So, a better story is to use bzr as if it were svn at that point: bzr co the trunk, bzr merge your changes, and bzr commit. If the Launchpad import of a given SVN package was recently created (since late 2009) then it works quite nicely. If it was made earlier, you will encounter hiccups. With the new imports I've done stuff like this. - bzr branch the import from LP. - Make changes locally and commit. - push branch to LP - make a merge proposal on LP and get a review - bzr push the branch to a new branch on zope's svn (each commit you made locally shows up separately even though it is one big push) - bzr co the svn trunk, merge my changes, and commit. It's quite nice. Handling merges is wildly nicer in the correct dvcs options than svn. The only limitation for bzr right now is that bzr doesn't handle svn externals. That's slated to change this year, I think. If people are curious, Sidnei or I could reach out and get more details of the timeline. - From my research, support for svn:externals in bzr-svn is actually blocked on an upstream bzr feature which is itself stalled (no activity for 2 years now, I think). Yes. That's the thing that should be worked on soonish. svn:externals are already kind of a wart, although recent SVN versions have fixed one long-standing issue (they allow relative externals now). I think we have a few recurring patterns in the repository: - using an external to pull in $ZSVN/bootstrap, rather than copying the bootstrap.py file. I'm ambivalent here, and could easily see dumping the external. - using an external to work around setuptools' inablility to install headers in a useful way, e.g. Zope's 'include' directory. Maybe a new recipe would be better? Not clear if it would help, but I'm actively maintaining z3c.recipe.filetemplate. In the process of adding support for relative paths. - using externals to stitch together omnibus buildouts, e.g. CMF.buildout. We could probably use something like 'infrae.subversion' instead, maybe with a hook that allowed local customization of the command used to fetch the sub-checkout. That would be cool. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Summary of this weeks' meeting (2010-03-30)
On Mar 31, 2010, at 11:16 AM, Christian Theune wrote: Hi, here's this week's summary. For those of you who can't/don't participate in those meetings, there's the open question about how useful you consider my summaries to be. Please tell! I read them and appreciate them. Thank you. Gary ___ 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.testing 3.8.7: downgrade the deprecation warning
On Jan 26, 2010, at 7:49 AM, Marius Gedminas wrote: I got tired of seeing things like /home/mg/tmp/buildout-eggs/zope.testing-3.8.6-py2.5.egg/zope/testing/testrunner/debug.py:23: DeprecationWarning: zope.testing.doctest is deprecated in favour of the Python standard library doctest module from zope.testing import doctest and since zope.testing's trunk hasn't got the problem fully licked yet (importing zope.testing.renormalizing causes a deprecation warning about zope.testing.doctest), I created a 3.8 branch based on the last public zope.testing release (3.8.6), downgraded the DeprecationWarning into a PendingDeprecationWarning, and released zope.testing 3.8.7. zope.testing's trunk is henceforth known as 3.9.0pre. Any ideas about fixing the deprecation warning caused by renormalizing.py? All it does is 'import doctest' which, due to Python's unfortunate import semantics, is interpreted as 'from zope.testing import doctest' Perhaps a from __future__ import absolute_import would help at the top? But it's only availably starting from Python 2.5, and I think zope.testing wants to be compatible with Python 2.4 too. Ideas? There's always the pre-2.5 icky __import__ hack for this if you need it. You probably know it, or I can look it up if you want, but that's the only approach I know of for this kind of issue in pre-2.5 Gary ___ 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 ?
On Jan 22, 2010, at 4:51 PM, Lennart Regebro wrote: On Fri, Jan 22, 2010 at 22:44, Hanno Schlichting ha...@hannosch.eu wrote: On Fri, Jan 22, 2010 at 10:37 PM, Lennart Regebro rege...@gmail.com wrote: I also don't know of any applications running on the other frameworks, which is why it's so empty there. SchoolTool and Launchpad have been mentioned as Zope3 applications in the past. Karl would be an example for BFG. Not sure if there's a canonical example for Grok. Ah, yes, Schooltool and KARL, of course, I forgot about them. Is Launchpad available as an application you can install and run? Nominally, yes. If you are willing to let it have its way with your system. Gary ___ 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
Yeah, I was thinking that too, as a I don't have time to think hard about this little daydream. Actually I believe you would want to subclass InterfaceClass and make your new zope.component.Interface an instance of the new InterfaceClass and specify zope.interface's Interface as something it extends. Then packages in the Zope world would start to use that Interface, I'd guess. I don't know how I feel about it. Gary On Dec 17, 2009, at 11:51 AM, 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. - 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 ) ___ 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] ZCA summary so far...
On Dec 3, 2009, at 1:54 AM, Chris McDonough wrote: My $.02 is here: http://www.plope.com/Members/chrism/zca_thoughts_summary I was going to comment on your blog, even though it was separate from the mailing list, but then I couldn't register an account, so here I am. I agree with a decent chunk of what you say. I guess my experiences working with new and casual ZCA users in Launchpad are somewhat similar to your BFG experiences. I'm very interested in working on changes in the underlying registry. Like you (I think), I'd also like to support the ability for using classes and abcs for specs. I have some work in that direction. I also want a better debugging API, which I have also investigated. We might disagree on the specifics, but it sounds like we're similar in broad desires there. I also agree with many of your perceptions of what we have: the experimental package I have started that subsumes the jobs of zope.interface and zope.component is called pluggable, which echoes one of your points. I don't think replacing these packages is a practical way forward, but it helps me think and imagine. I think that moving forward might be easiest to do by making the adapter registry pluggable in zope.interface and zope.component, and working on this in another package.At that point, interested users of zope.interface and zope.component could choose to use our registry (and perhaps it might evolve to become the blessed registry at some point); and we could provide alternative ways of using the package, separate from zope.component and zope.interface. We should collaborate. In my copious spare time I would like to call you and see if you and I can at least agree on some experiments in this direction. I'd like it if my work had some chance of uptake in BFG. I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. Gary ___ 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] internal improvements to zope.component Was: ZCA summary so far...
On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote: Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. I didn't follow this until I squinted at it and came up with I'd like us not to make any API improvements on looking up things dependent on underlying refactorings. That sounds reasonable. * I'd like to see some underlying refactorings in zope.component/zope.interface. A broad agreement, but an agreement nonetheless. * I'd also like to see a better registration API I don't have that pain point ATM, but I can vaguely see where one might. * documenting this clearly (and perhaps in advance of any actual work) is important. +1 on documenting. -1 on not allowing some experiments to happen first. * I'd like to keep zope.interface and zope.component backwards compatible and still benefit from the improvements. +1 * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. I'm +1 on that as long as it can be rephrased to ...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities. * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I am not a fan of design by committee. I do think a community (committee) often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them). * I *also* would like to take a range of optional dependencies out of zope.component, however. The ZCML directive implementations in particular. I don't have that pain point ATM, but I can vaguely see where one might. * but I'd be fine if we got a better API and implemented the old APIs on top of these. * and we might eventually deprecate the old APIs. Agreed. Gary ___ 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] internal improvements to zope.component Was: ZCA summary so far...
On Dec 3, 2009, at 12:08 PM, Martijn Faassen wrote: Gary Poster wrote: On Dec 3, 2009, at 10:51 AM, Martijn Faassen wrote: Gary Poster wrote: [snip] I personally think these efforts do not make the potential consensus on ``adapt`` and ``utility`` methods any less interesting: they would be a concrete win for my users. I agree with much of what Gary is saying here. My ideas: * I'd like us not to make any lookup API improvements on looking up things dependent on underlying refactorings. I didn't follow this until I squinted at it and came up with I'd like us not to make any API improvements on looking up things dependent on underlying refactorings. That sounds reasonable. Sorry, that wasn't very clear. I just meant that we should improve the lookup API not waiting for underlying API changes to materialize. These processes should be decoupled. If from underlying API changes we come up with even better lookup APIs, so be it. Ah, I see (and I didn't before). Yes. * I'd like to see some underlying refactorings in zope.component/zope.interface. A broad agreement, but an agreement nonetheless. * I'd also like to see a better registration API I don't have that pain point ATM, but I can vaguely see where one might. Where is your pain point? There are many concerns that my interviews raised. I talked about them in my OSCON talk, and they are at the heart of my PyCon talk. You and Chris appear to share somewhere between many and all of them, between you. I don't have time for more details than that right now. ... * Therefore, any rethink of the internals can be substantial but not so fundamental as to drop interfaces or the ideas of adaptation and utilities. I'm +1 on that as long as it can be rephrased to ...can be substantial but not so fundamental as to drop interfaces or the *support for* the ideas of adaptation and utilities. Sure, we don't want to drop support either. :) My point is that I don't find net value in the names, especially adaptation, as I've said repeatedly. I don't want them to be necessary in lower-level APIs that I teach and promote. I'm happy to continue to have internals that can *support* APIs that use the adapter names. I don't want them to *use* those names. The confusion in message here I think is because of your next point, on which we disagree. * Preferably I would like these things to take place in zope.component and/or zope.interface. Experimental packages are all right, I guess, but I wouldn't want them to be permanent. Let's keep the user community together on this one, please. I am interested in a package that gives the pluggable functionality I want but that does not depend on zope.component, but that zope.component can or does depend on. I don't want zope.component become a shell on some other package with a better API. I know that that's often how we work, but I'd like to try to make zope.component itself that better package. I don't think we are at a point that debating this is worthwhile, at least from my perspective. I still want to see what of my own pain points I can remove, without the constraint you describe. I'll be better able to debate (or concede!) once I have done that. I am not a fan of design by committee. I do think a community (committee) often has better ideas than a single person. Certainly I feel comfortable saying that when the single person is myself. I reconcile these positions by feeling that a very small number of people should design packages initially. Then the community can take them, take them and modify them, or leave them (ideally learning from them). I don't want this to be a take it or leave it situation. I'd like there to be some commitment to making this package work for the whole community. I do not want this to be another vision that in the end the community can't use because we still depend on zope.component. If the community *can't* use my work, then it is wasted. I don't want that. I want it to be valuable. I especially want Launchpad to be able to use it easily, and we use a lot of Zope community packages. That said, it's a risk one takes on projects like this sometimes. I'll try to mitigate it. Gary ___ 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] the ZCA API decision
On Dec 3, 2009, at 3:33 PM, Thomas Lotze wrote: Martijn Faassen wrote: Thomas Lotze, are you happy enough with this to still help with the implementation? I am indeed. This isn't the ideal solution I had hoped for, but it is a big step in a good direction from my point of view and I don't see any part of it that might take us away from the ideal solution which I still hope we can implement at some point in the future. How are we going to organise the work? Do you intend to sketch out a plan for action? Should everyone create their own branches and experiment for a while first? I don't know if too much experimentation is needed for this in particular. I would think we would want to follow the pattern of the adapter_hooks in zope.interface.interface, including the C optimizations. I would be comfortable with you leading the effort, in a shared branch, if that works for you. You could specify what parts you wanted help on. Or would you prefer someone else to take charge? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Dec 2, 2009, at 8:33 AM, Fred Drake wrote: On Wed, Dec 2, 2009 at 2:21 AM, Thomas Lotze t...@gocept.com wrote: To be honest, I just don't see why this whole singleton business shouldn't be orthogonal to the concepts of the component architecture. Well said. If an application cares about singleton creation or ownership of factory-returned objects, it can describe those requirements using interfaces. You are arguing for the unification of utilities and adapters? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Dec 2, 2009, at 8:58 AM, Fred Drake wrote: On Wed, Dec 2, 2009 at 8:42 AM, Gary Poster gary.pos...@gmail.com wrote: You are arguing for the unification of utilities and adapters? No. I'm arguing not to conflate utilities with the singleton pattern or adaptation with ownership of the resulting adaptation. OK. I have given up on the singleton presentation. I still think that it has as much validity as comparing adaptation to type casting, but let's leave it. It's dead. The ownership issue is just a small part of the larger picture that I address below. On Dec 2, 2009, at 9:19 AM, Thomas Lotze wrote: I think the difference between these two perspectives may have to do with why some people in this discussion confuse (as I see it) the concepts of instance vs. factory registration and adapter vs. utility lookup. It's not a matter of confusion in my mind. It's a matter of trying to present these ideas in a way that people who do not use these ideas frequently understand and remember easily. I think the difference is between the perspective of people who use these tools day in and out, and are already comfortable with them; and the perspective of people who want to make the ideas easy to use and remember for introductory and casual/intermittent usage. If Python presented classes as abstract callables that can do whatever the heck you want, I don't think that would be particularly useful. That's what they are, but we mostly use them as factories. They are generally explained as factories. The exceptions are that: unusual exceptions to the rule and basic idea. Instance vs. factory registration is a clean way of distinguishing between utilities and adapters. adapters is IMO not an accurate description of how we use multiadapters (and certainly not subscription adapters, which is another whole ball of wax that has a different solution IMO). Without this distinction, AFAICT either you want to conflate the ideas, or you have a concept of the differences between the two that is more esoteric than I think is useful. I get the impression that it is on the second point of those that we disagree. Gary ___ 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] ZCA summary so far...
...from my perspective. = Things vaguely approaching consensus = == General == There's a consensus that changes to the ZCA need to be backwards compatible. The practical definition of that varies for different people. == Syntactic == === Tuple multi-adaptation === Example: IFoo((bar, baz)) == z.c.getMultiAdapter((bar, baz), IFoo) - It has the most consensus of any proposed change so far. - It is concerning because it breaks backwards compatibility in two real world use cases from the very small set of Zope users who actually watch zope-dev. There is a workaround spelling at least, but it is ugly (i.e., what was ``IFoo((bar, baz))`` will need to become ``IFoo(((bar, baz),))``). - It is easier to remember than ``z.c.getMultiAdapter((bar, baz), IFoo)`` (I always have to look up the order of arguments for getMultiAdapter myself) but not as easy to remember as ``IFoo(bar, baz)``. It introduces yet another spelling of the same thing (e.g., ``IFoo(bar)`` is the same as ``IFoo((bar,))``. == Utilities available from interfaces == As far as I can tell, no one is against this generally, and several people are for it. Some people are against the syntax that has been proposed for this that merges utilties and adapters (see No consensus section below). An alternate syntax was proposed involving a ``utility`` callable. This made the most sense when it was paired with an ``adapters`` (or ``factory`` or ``new`` or ``instance`` or ``create``) callable, which contradicts the consensus of the tuple multi-adaptation section above. = No consensus AFAICT = - Utilities and adapters should be merged. - We care significantly about new and casual users and perceive that the current API does not serve them well. - Adapters are usually used as factories, and utilities are used as instances, and it is valuable to present them that way. Related: the term adapter buys us little and costs us more than nothing among new and casual users. = Rejected = - Utilities should be called singletons. ___ 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] ZCA proposal
I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) = Why? = - This is a significant improvement in terms of being memorable, as far as I'm concerned. It's also briefer, which is related. - It uses the terms we've already taught. - It is entirely backwards compatible. We don't have to poll the world and hope we didn't miss anyone. - We can make the call syntax for ``adapt`` take multiple arguments. - It is symmetric-ish. - It would potentially allow a place to hang debug/analysis calls, as I showed earlier, but let's not have that debate yet. I can put those somewhere else if I need to. = Why not tuple multi-adaptation in the __call__? = I'm somewhat surprised that some who have been loudest about not breaking backwards compatibility are OK with breaking this, given the two reports from the very small sample we have here of users. I think it is unnecessarily risky for minimal gain, particularly when we have another reasonable option. = But Gary, I thought you didn't like ``adapt``? = No, I don't. I think it is a hindrance to understanding, and I would prefer ``instance``, for example (or maybe ``create``?). That said, people disagree with me. Going along with ``adapt`` but getting this new syntax gets me a lot of improvements from my perspective. I think people on the Launchpad team would be happy with this. I would explain ``adapt`` as look, it's a factory, but, oh well. Progress usually means compromise. = But Gary, I thought you didn't like ``utility``? = No, I don't. I already gave up on that one, since I didn't have an answer better than singleton and I acknowledge that it is not great (either, for different reasons). Gary ___ 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] ZCA proposal
On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote: Gary Poster wrote: I think I could get fully behind the following proposal that others have made (Shane I think was one of several?). IFoo.adapt(...) IFoo.utility(...) I could get behind this too. We'd need the current IFoo(context, default) for single adaptation to continue to work, and I *wouldn't* deprecate it with a warning, since it'd just lead to a lot of warnings. We'd obviously also want the existing get*() methods to continue to work. Not sure which get* you mean (get* and query* in ZCA?) but generally agree that we are talking about adding, not removing. Gary ___ 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 discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 9:54 AM, Chris McDonough wrote: Martijn Faassen wrote: ... I am also in favor of unifying adapter and utility lookup. Or at least creating a more normalized API. I guess it is no surprise that I am in favor of a normalized API but against the unification. On the syntax of the change: [...] I followed vaguely. This was about unification, correct? On the semantics of the change: Personally I think that it's a fantasy to believe that the difference between an object created via a factory on-demand and an object simply returned should *never* matter to a caller. You may not want the caller to need to care, and it may be inconvenient to take into account circumstances where the caller needs to care. But because this is Python, the caller still often does need to care. Again, no surprise that I agree with this and following. Gary ___ 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 discussion was: adapter vs factory Re: implementing zope.component 4.0
On Dec 1, 2009, at 8:21 AM, Martijn Faassen wrote: Hi there, I'd like to summarize the options I've seen appear in the discussion so far. We have the following options: 1) introduce a new method, such as instance() or lookup() on instance. It unifies utilities with adapters. We can make it do whatever we want without worrying about backwards compatibility. 2) introduce several new methods that distinguish between utility and adapter lookup. We can make them do whatever we want without worrying about backwards compatibility. 3) call the interface, which unifies adapter and utility lookups. Use tuples for multi adaptation. We think could make this work without *too* much backwards compatibility issues (pending research on how prevalent tuple adaptation really is). In the long term we can even map out a deprecation strategy that can smoothly migrate us to a multi argument approach. 4) call the interface, which unifies adapter and utility lookups. Use multiple arguments for multi adaptation. The backwards compatibility obstacles are largest here as we already have the default argument. We'd need to introduce multiple modes to selectively upgrade. You are leaving out the variants of 3 and 4 that allow calling the interface to support multiadaptation, but do not unify utilities. My impression is that I am not the only one who is not pleased with the proposed unification of utilities and adaptation. My impression is that we are nearing consensus on the variation of 3 that does not include utilities. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 30, 2009, at 4:05 AM, Brian Sutherland wrote: On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote: On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote: Hmm, I may be missing something here, but if Foo implements IFoo, then the getAdapter lookup for it will short circuit, leading you into infinite recursion. Except that it doesn't: [snip example] which strikes me as wildly disjoint: the IFoo behavior is expected (short-circuit the lookup if the object already provides the interface), while the getAdapter behavior is a puzzlement. This has been mentioned numerous times as one of those odd and unexpected differences between the IFoo vs. get/queryAdapter semantic. IIRC the only use-case I ever heard of for the getAdapter semantic, was the possibility to override the behavior promised by the interface with a different adapter without touching the class that implements the interface directly. I think changing this falls into the category of: Small backwards incompatibly that seem worthwhile to make the behavior consistent and expected. I do agree that this behaviour is inconsistent with the common idea of adapters in the ZCA. So it doesn't have to be in the main API to the ZCA, i.e. the one people most heavily and frequently use. But, I'll argue that it should be still possible if you are willing to go outside the main API. My particular usecase is Location objects implementing IPublishTraverse without depending on the default traversal adapter: class FakeContainerOfSomeKind(Location): implements(IPublishTraverse) def publishTraverse(self, request, name): if name.isdigit() and do_i_contain(name): return get_the_object_i_contain(name) # fallback to default traversal adapter without depending on it traverser = getMultiAdapter((self, request), IPublishTraverse) return traverser.publishTraverse(request, name) I wouldn't know how to implement the above code without either depending directly on the default traversal adapter or making an IDefaultPublishTraverse marker interface. Neither of those, in my opinion, is as elegant as the above. I'd argue what you have is pretty obscure though--that is, reading your code example, I'd have to stare at it a while to figure out why it works, and I know the component machinery pretty well. The IDefaultPublishTraverse thing would be inelegant but much more readable. I'd want to think about this class of use cases harder if it were regarded as an important one. I am myself somewhat interested in being able to turn off the short-circuit behavior explicitly if desired. That said, for multiadapters involving more than one required object, IMO the short-circuit behavior should never be invoked. It is not clear that the first object is the one that should be checked for already providing the desired interface. Therefore, in this particular usage, ``IPublishTraverse(self, request)`` would do what you want. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Hi there, Introduction So now that we've had some discussion and to exit the bikeshed phase, Wow. That's abrupt, for something at the root of the entire stack. I don't think long emails are very effective, but I'm not sure how else to reply to your long email. let's see about getting some volunteers to work on this. The goal here is to make interfaces disappear into the language as much as possible. This means that I'll ignore backwards compatibility while sketching out the ideal semantics below - I have the impression we can get consensus on the following behavior: Simple adaptation: IFoo(adapted) Named adaptation: IFoo(adapted, name=foo) Adaptation with a default IFoo(adapted, default=bar) Multi-adaptation: IFoo(one, two) Named multi adaptation: IFoo(one, two, name=foo) Multi-adaptation with a default: IFoo(one, two, default=bar) I am in favor of the above, given a backwards compatibility story that makes existing packages work. Utility lookup: IFoo() Named utility lookup: IFoo(name=foo) Utility lookup with a default: IFoo(default=bar) I disagree with this. More below. Where name and default can be combined. The name and default keyword parameters have to be used explicitly - *args is interpreted as what to adapt only. Any other keyword parameters should be rejected. Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. As a matter of mechanics, when you register something we call an adapter, it is a callable that takes one or more arguments. If we were going to follow the pattern that Marius laid out to establish what happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. Two by-the-ways: 1) The term adapter is a barrier to understandability, in my interviews. This is particularly the case when people are introduced to the idea of multiadapter and supscription adapter. In what ways are these anything like a type cast? IMO, they are not. Our usage of adapter is as a factory. Yes, it can be used in other ways--so can a Python class--but that is the essence of how our community uses this technology. Calling all these ideas adapters accomplishes nothing. Explaining all of the ideas as a factory to produce an object that provides the interface cleanly describes our usage, and both adapters and multiadapters. (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) One reason I like the syntax proposals for the adapter change is that they treat the interfaces as pluggable factories. This is apt. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought on the debugging story, and have some APIs sketched out in my experiments--it was one of the first things I
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 11:51 AM, Chris McDonough wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: Utility lookups versus adapter lookups -- There was some discussion on whether utility lookups are really something fundamentally different than adaptation as adaptation *creates* a new instance while utility lookup uses a registered instance. I think the essential part here is however: give me an instance that implements IFoo, and utility lookup fits there. We could even envision a way to create utilities that *does* instantiate them on the fly - it shouldn't affect the semantics for the user of the utility. As above, I disagree. The root of the disagreement here is that you seem to want the *caller* to care about something which is important only to the person who *registers* the thing being looked up. From the caller's perspective, the call site needs an object implementing IFoo, looked up using some number N of context arguments, where N could be 0 (no context required to find the object). The fact that, under the hood, an adapter lookup happens to call a factory, passing the context args, is not relevant *to the caller*. I understand that the idea explained above is conceptually integral to a lot of people, and basically unquestionable. But as devil's advocate sort of thing can we put this traditional worldview aside for a minute, and just sort of take this from ground zero? In normal Python, callers often do need to understand whether the function they're calling is a factory which constructs a new object, or a function which returns a global, because the caller needs to know what the impact of mutating the result is. We call non-factories utilities and we call factories adapters. So the caller *already* needs to make a distinction between the two. Yes. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 1:51 PM, Chris McDonough wrote: Shane Hathaway wrote: ...a good general argument, that Chris seemed to agree with and expand upon, and that has some merit to me. What do you think? + 1 with the following caveat: I think that method name should probably be adapt; lookup should maybe be a separate method reserved for passing bare interfaces rather than objects which implement interfaces, e.g: ... 1) I very much like the idea of some helpers hanging around. However, my current belief is that the factory methods ought to be callable objects that allow introspection of the underlying registry. That's where the lookup style behavior belongs, IMO, as well as other helpers. See below for examples. 2) As argued before, I think that adapt is an ok name for a single object, but becomes a bad name once you have multiadapters in the mix. I would prefer one of the options Matthias Lehmann proposed (new for instance). 3) I also think that utility is a bad name. Is singleton two letters too long? If it is, I mind utility less than I mind adapter. IFoo.new(a, b) # finds and returns result of call IFoo.new.lookup(IA, IB) # finds and returns callable IFoo.new.find(IA, IB) # get all registration information IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration information for each registration for those two interfaces IFoo.singleton() # finds and returns item IFoo.singleton(name='baz') # finds and returns item IFoo.singleton.lookup(name='baz') # same result in this case IFoo.singleton.find(name='baz') # get all registration information Side, but related point: I wonder if there is value in the ability to spell IFoo.singleton(a) # where a is a required object to the registration. This would make utility registrations more powerful in a way that some people seem to have been missing. It also makes things parallel with creation. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 11:47 AM, Martijn Faassen wrote: Hey, Gary Poster wrote: On Nov 27, 2009, at 6:32 AM, Martijn Faassen wrote: ...snipping here and elsewhere without further warning... Utility lookup: IFoo() Named utility lookup: IFoo(name=foo) Utility lookup with a default: IFoo(default=bar) I disagree with this. More below. [snip] As a matter of mechanics, when you register something we call an adapter, it is a callable that takes one or more arguments. If we were going to follow the pattern that Marius laid out to establish what happens when, then we have this, roughly: register callable that takes two arguments: IFoo(bar, baz) register callable that takes one argument: IFoo(bar) register callable that takes no arguments: IFoo() If instead we have the last step as what is proposed here register non-callable IFoo() then I think that breaks an important pattern for usage understandability. I still don't see why that isn't an implementation detail. How we get an IFoo doesn't concern us when we're calling it, as long as we get an IFoo? Even with adaptation a singleton could be returned; it's just the implementation of such would be different. The people I know are involved in both registration and usage of these things. If we take Marius' pattern, registring a singleton directly would simply be a shortcut API for registring a factory for utilities. (Utility factories would make it easier to implement local utilities that aren't ZODB-backed...) Make those factories that do not take arguments. That's the use case for IFoo(). That is, IFoo() can have a semantic if that is valuable, but it is not the same as registering and getting non-called singletons. What is this valuable semantic? Marius said he has had a use case. It sounds like you gave one above. [snip] (To be complete, I am in favor of ditching subscription adapters in favor of other mechanisms related to named singleton lookups.) I really need to think through subscription adapters; I haven't done any analysis about those. 2) The term utility is another barrier to understandability. They are singletons. Explaining them as such is a well, why didn't you say so experience. Another way to explain utilities is that getting a utility is a lot like importing something in Python, except that what is imported is pluggable and the required interface is specified explicitly. Therefore, I am in favor of removing the necessity to use the word utility. That said, they are not factories. They should not be mixed with the two. My preference for future changes is to have an API using the ``singleton`` name. import by interface to me sounds like it'd clarify matters for more Python programmers. Singleton has all kinds of design pattern connotations that don't really apply here. Moreover, I think that some of the use cases that Marius referred to for underpowered utilities coud be remedied by having a utility/singleton lookup that allowed looking up by required values like the adapter/factory lookup. I don't understand. Could you rephrase? Right now you can only look up a utility with a desired output, and optional name. Is it useful to also be able to pass in a context of objects for the lookup (the required values in the underlying implementation)? Features off the table for now --- Saying an interface is implemented by a class (Python 2.6 and up) with a decorator we'll leave out of the discussion for now. It would also be come up with an improved API to look up the adapter *before* it is called, but I'd also like to take this off the table for this discussion. It seems to me that this, along with the documentation call that Chris gave, is a much more valuable immediate effort. One of the biggest complaints I heard was with debugging. I've spent some thought on the debugging story, and have some APIs sketched out in my experiments--it was one of the first things I worked on. To do it cleanly (the way I envision) would require some work, but a first cut wouldn't be too bad. Hm, I disagree about what's more valuable. Sure; we have different perspectives on who we are aiming for. You have said you are not aiming for new/non-expert users, at least in this round. In contrast, they are my primary clients. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote: Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster gary.pos...@gmail.com: 1) I very much like the idea of some helpers hanging around. However, my current belief is that the factory methods ought to be callable objects that allow introspection of the underlying registry. That's where the lookup style behavior belongs, IMO, as well as other helpers. See below for examples. 2) As argued before, I think that adapt is an ok name for a single object, but becomes a bad name once you have multiadapters in the mix. I would prefer one of the options Matthias Lehmann proposed (new for instance). I have no great problem with multiadapters as long as the analogy is clear enough - this adapter takes two sources... Well, my first issue is that the adapter word is unnecessary by my definitions. Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to the wall (output interface). Is there a common real-world example of this for multiadapters? 3) I also think that utility is a bad name. Is singleton two letters too long? If it is, I mind utility less than I mind adapter. I don't understand this. For me a singletons is (sic) a highly specific programming term whereas adapters and utilities, especially in the way we refer to them, are not so domain specific. Turned around, people know the term singleton and they do not know the terms adapters and utilities. singletons describe the huge majority of how we use these things. It's something less to explain. Making comprehension quicker is very valuable to me. Put yet another way, how are 99+% of our utility usages not singletons? If that's the case, what's the value of having to explain what a utility is? How do you reply when the people you support say, oh, so this is just a singleton, right? That said, and to repeat, I mind adapter more than utility. IFoo.new(a, b) # finds and returns result of call IFoo.new.lookup(IA, IB) # finds and returns callable IFoo.new.find(IA, IB) # get all registration information IFoo.new.find_stack(IA, IB) # get an iterable of the stack all registration information for each registration for those two interfaces IFoo.singleton() # finds and returns item IFoo.singleton(name='baz') # finds and returns item IFoo.singleton.lookup(name='baz') # same result in this case IFoo.singleton.find(name='baz') # get all registration information Interestingly this is starting to look too verbose and java like to me but I'm also not happy with the use of new or singleton. find might be an idea if it could use introspection to gives clues as to what I might actually want to do with my IFoo implementers. Can you give some sample responses? The majority of those were advanced, or debug usage. That's the kind of thing that Chris was talking about, at least in my estimation if not in his :-) . Here's basic usage. I'll use utility since I'm getting more pushback on that one. :-) ``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo) ``IFoo.utility()`` gives you the singleton registered for IFoo. That's the basic idea. It's basically what Shane proposed, with the adapter - new thing (and my squelching of utility - singleton). What if you want to determine how you got the result that you got? You need some additional methods. My proposal was that you put those methods off of ``.new`` and ``.utility``. You could also make other methods (or objects) off the interface. In my experiments, I have the following debug and utility/advanced methods. You would typically only look at these if you were trying to figure out what was going on, or if you were doing something tricky. .lookup (what Chris proposed) .lookup_all (also based on the registry call of the same method) .find (get registration information--that is, value, required, provided, name--for the same input as lookup) .find_all (get registration information dictionary for the same input as lookup_all) .find_stack (returns an iterable of registrations, beginning with the one that would have been chosen, and following with the registrations that were masked by that one.) .__iter__ (iterate registrations for output interface) .find_for_value (returns an iterable of registrations for output that have the given value) These are also on the underlying shared registries, with similar meaning. Side, but related point: I wonder if there is value in the ability to spell Could someone please point me in the direction of the definition of this use of spell? Is it short for spell it out? A spelling in this sense is a specific API for an idea. I was asking about the *ability* to spell--whether this kind of usage was interesting. Gary
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 4:13 PM, Zvezdan Petkovic wrote: On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote: On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: 3) I also think that utility is a bad name. Is singleton two letters too long? Yes and not because singleton is longer. It just a bad name. :-) To clarify because of 1. the typo above (should be It's just ...); 2. the preposition it used. I meant: Singleton is a bad name. I've given my reasons (the most recent attempt was to Charlie Clark). You give yours. :-) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] adapter vs factory Re: implementing zope.component 4.0
On Nov 30, 2009, at 5:14 PM, Lennart Regebro wrote: On Mon, Nov 30, 2009 at 22:40, Gary Poster gary.pos...@gmail.com wrote: Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object). Power adapters, for instance, adapt a plug (required interface) so it can plugged in to the wall (output interface). Is there a common real-world example of this for multiadapters? Yup. http://www.amazon.co.uk/Scart-Adapter-Switchable-Plug-Socket/dp/B00077DC6A Audio + Video in: SCART out. :) heh. And Shane's example was more commonplace. I still think this is unusual, or in Shane's example, not something that people think of as a multiadapter. But as said, to Fred, point partly taken. :-) [snip utility/singleton] That said, and to repeat, I mind adapter more than utility. But adapter is really what it is. OK, Multiadapters are evidently complicated... But is it really so complicated that we should throw away the commonly accepted GoF for what clearly are adapters? How is it less confusing to call IFoo.instance(x,y) than IFoo.adapt(x,y) or even IFoo(x,y)? I am very much in favor of IFoo(x, y). That makes me very happy. It looks mostly like you are instantiating a class, except that it looks a bit funny: in my view, it is a reasonably good leaky abstraction for what is going on. People also like the compactness of the spelling, in my discussions. They also remember it very well, even over long periods of not using the API. This is a big deal. Backwards compatibility is the problem. I need to go have a life. :-) Talk to you all tomorrow. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote: ... Thoughts? FWIW, this mirrors some of the thoughts I've had, after a lot of discussions with Launchpad/Canonical engineers about the pros and cons of the Zope interface and component code. My OSCON presentation touched on some of these discussions, observations and ideas. Ideas on addressing the problems in the feedback are the focus of my upcoming PyCon presentation. I'm in the middle of an experiment to modify the code without backwards compatibility concerns, to see where it takes me. Obviously, there's an extremely high hurdle for backwards incompatibility, but it was the experiment I wanted to pursue, and one that (obviously) I felt had merit. My intent is to show these at PyCon and start a discussion about the value of the changes, what could be done without breaking backwards compatibility, what could be done with minimal backwards compatibility breakage, and if anything I discovered merits more significant breakage. I'd prefer to think about these myself for a while, and continue to experiment. I've already digested a lot of feedback, from the interviews at Launchpad and Canonical, from past mailing list discussions, from documents like BFG's design defence (http://docs.repoze.org/bfg/1.1/designdefense.html), and from personal discussions. Most people have heard some variation of the (perceived/real) problems before; I'm not ready to settle on my preferred solutions myself. I'm seeing how everything fits together, and it's a big puzzle to assemble. My experiments don't need to hold anyone else up, of course, but I do have a concrete deadline to deliver something. :-) I'll share once I feel that I am reasonably happy with my choices, which may or may not be significantly before PyCon. If other folks want to run on without me, I can at least point to the slides for the OSCON talk I gave with the Canonical/Launchpad feedback if you are interested. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: Martijn Faassen wrote: Adapter: IFoo(x) [...] Multiadapter: IFoo.multi(x, y) [...] Utility: IFoo.utility() [or possibly IFoo() instead?] What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. They are too different. Our use of adapters generally involves looking something up and automatically calling it. Our use of utilities generally involves simply looking something up and returning it. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote: Gary Poster wrote: On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote: What about a simple and consistent API for all components including utilities, adapters and multiadapters: IFoo() IFoo(x) IFoo(x, y) I seem to remember there had been some discussion at some point about dropping or at least loosening the distinction between utilities and adapters anyway, so this would be the opportunity to do so at the API level. That was discussed and rejected near the very beginning of the Z3 effort, in my memory. OK. If that was a hard and fast decision, I'll not argue further. FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote: Gary Poster wrote: FWIW, I'm saying that utilities and adapters are different. I share your/Martijn's/other people's general thoughts about merging adapters and multiadapters in the interface __call__ syntax. There might should be more obvious APIs for just *retrieving* an adapter based on a set of interfaces; it's useful to be able to retrieve an adapter without invoking it. Currently this is possible via registry.adapters.loookup, which is fine. And I know it's heresy, but sometimes I register something as an adapter that is not callable with the number of arguments I'm adapting it with. Sometimes its convenient to register something that gets adapted using a number of arguments that doesn't match the adaptation arguments. If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). Yeah, this is one of my goals too. Gary ___ 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] split out zope.component mechanics into a separate package (was Re: improving the utility and adapter lookup APIs)
On Nov 25, 2009, at 5:08 PM, Chris McDonough wrote: Chris McDonough wrote: If some set of ZCA APIs made it the responsibility of the *caller* to invoke the adapter with arguments would go a long way between normalizing the difference between utilities and adapters (because they would essentially then be the same thing). The very core mechanics of how a component registry behaves resides almost entirely in the zope.component.registry module. It would be useful to split these core mechanics into a separate package. Here's why: - The zope.component module carries along an expectation of a particular global API. This global API is not required to use the mechanics of the underlying registry machinery. - The zope.component package has a number of features that are irrelevant to the operation of the core registry itself, such as persistence and security. - The registry itself is useful outside the context of the zope.component API package; the API is essentially just candy on top of the registry itself. I have created such a package at http://svn.zope.org/Sandbox/chrism/zope.registry It contains an implementation of the registry and the tests for the registry object. It depends on zope.interface and zope.event. I'd like to actually remove the zope.event dependency and release a newer version of zope.event that uses a global inside zope.registry as the list of registered object (reverse the dependency). After that's done, I'd suggest we make zope.component depend on zope.registry. At this point, people can innovate with their own APIs to the registry object as necessary; they needn't carry along the baggage of the expecation of the older zope.component API working in their app. Thoughts? FWIW, it's not of a lot of interest to me. I'm interested in changing things at a lower level. However that works, if I manage to build zope.component backwards compatibility as an add-on then I'll have to worry about all of the bits in zope.component, not just this. Gary ___ 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 note on the PyCon Program committee.
On Nov 3, 2009, at 4:48 PM, Chris McDonough wrote: Gary Poster wrote: ... It is an advocacy piece only in the sense that we are saying that, by-and-large, we like what the packages give us, but it is more challenging than that. It's an interesting pairing to Jeff Shell's invited talk, which appears to cover some of the same ground from more of an advocacy/tutorial perspective. I was honestly a bit surprised that mine was accepted when Jeff's was already scheduled, but maybe mine is the dark side version of his talk. :-) It's Jeff Rush.. Bah, I knew that. Thanks for the correction. Sorry, Jeffs. Gary ___ 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 note on the PyCon Program committee.
I had a rethinking interfaces talk accepted. It's about the positives and negatives of zope.interface and zope.component, driven primarily from the perspective and experience of the Launchpad team, and myself in particular; and about changes that might be made or differences we are interested in. It is an advocacy piece only in the sense that we are saying that, by- and-large, we like what the packages give us, but it is more challenging than that. It's an interesting pairing to Jeff Shell's invited talk, which appears to cover some of the same ground from more of an advocacy/tutorial perspective. I was honestly a bit surprised that mine was accepted when Jeff's was already scheduled, but maybe mine is the dark side version of his talk. :-) Gary On Nov 3, 2009, at 2:13 PM, Chris McDonough wrote: So were any Zope talks/tutorials accepted? FWIW, Tres had a BFG talk accepted, and Carlos had a BFG talk and a BFG tutorial accepted. I proposed a talk about profiling that didn't make it. The TG guys had one talk accepted. Not sure about Pylons. I assume Django had a bunch, but I don't know for sure. - C Martijn Faassen wrote: Chris McDonough wrote: [snip] Another way to avoid this in the future besides joining the committee would be for notable members of the Zope community to reach out on a regular (daily) basis to other Python-using communities. Offer them well- documented software, visit their sprints and conferences, try their alphas, join their IRC channels, participate in their maillists and so on. It's harder to do intercommunity politics daily in this way as opposed to facing off yearly, but it will have a higher, more lasting payoff. I'm very much in agreement on this. Blogging is another way to reach out. Reach out and interact. It's indeed hard work to do this right. I am sitting on a few pieces of software that are either interesting to non-Zope people or in fact directly usable, but I haven't had the time yet to blog about them. I intend to start blogging on a more regular basis again soon. It's who you know, not what you know unfortunately, even in open source, as much as we like to believe in meritocracy. That's true too. I'm a natural noise-maker, and I discovered that while as a result of this I embarrass myself in public on a regular basis, it also means a lot of people know who I am. That's a good thing. 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 ) ___ 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 note on the PyCon Program committee.
On Nov 3, 2009, at 3:28 PM, Lennart Regebro wrote: 2009/11/3 Gary Poster gary.pos...@gmail.com: I had a rethinking interfaces talk accepted. It's about the positives and negatives of zope.interface and zope.component, driven primarily from the perspective and experience of the Launchpad team, and myself in particular; and about changes that might be made or differences we are interested in. It is an advocacy piece only in the sense that we are saying that, by- and-large, we like what the packages give us, but it is more challenging than that. It's an interesting pairing to Jeff Shell's invited talk, which appears to cover some of the same ground from more of an advocacy/tutorial perspective. I was honestly a bit surprised that mine was accepted when Jeff's was already scheduled, but maybe mine is the dark side version of his talk. :-) Well, if you cover the good and bad sides, as your great OSCON talk did, but then also proposes what can be done about the bad sides, your talk would be of narrower interest, but also more important. :-) Cool, I'll aim for that. :-) I'm really sorry I can't go to PyCon this year, the talks are going to be awesome. Hopefully I can see the talk online at some stage. :) I'm sorry you won't be there too, but thank you! Gary ___ 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] Bazaar 2.0 (was Re: Subversion externals versus mirroring)
On Sep 14, 2009, at 2:02 PM, Gary Poster wrote: Once Bzr 2.0 comes out (in less than a month AIUI), I'll at least send out a link to it and point out some changes made that specifically address concerns raised by Zope Foundation members when I raised Launchpad's/Canonical's offer before. If there are any questions then, I'll be happy to try to get answers. Bzr 2.0 is out. I personally find the speed improvements very impressive. The new repository format is much smaller, and intended to be stable, and the project has a adopted a six-month maintenance release approach. It has a new website. http://bazaar-vcs.org/en/ It has a new front-end for Gnome/KDE/Mac OS X/Win. The screenshots look impressive to me, which is all I can vouch for. http://doc.bazaar-vcs.org/explorer/en/visual-tour-windows.html Cross-platform end of line conversion is implemented, which was one of the concerns raised earlier. http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#end-of-line-conversion I don't remember if anyone brought up the lack of a parallel to svn externals. That functionality (called nested trees for bzr) is not implemented yet. It is important to Launchpad's usage of the tool, though, so it is in the six-month pipeline, as I understand it. I'm happy to try to field any questions if anyone has any. Gary ___ 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] ZTK test failures - zope.testing
Hi. I didn't get it done on the 17th, but I did just make a release with the necessary fixes (or, the tests pass for me on Windows and Ubuntu, at least; they already were passing for me on Ubuntu, but I made the pertinent test somewhat less fragile). Gary On Sep 16, 2009, at 3:39 AM, Hanno Schlichting wrote: On Wed, Sep 16, 2009 at 3:53 AM, Gary Poster gary.pos...@gmail.com wrote: The Ubuntu one should be easy to fix. The Windows ones may be tied up with \n \r fun. It should be trivial too, though I'll need to get a Windows VM back up--or request aid from Sidnei. ;-) I'll address these issues tomorrow. Awesome. However, there is a Windows failure that I don't think is on my plate, and I'd appreciate someone else looking at it: zope.testing-3.8.2-py2.4.egg\zope\testing\testrunner\testrunner- test-selection.txt, line 166, in testrunner-test-selection.txt . That's the very last one on http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio . You refer to the ImportError: No module named c:.documents? I hope I fixed that one already, but didn't make a new release yet. That was the typical path with a space in it problem, as found in http://svn.zope.org/zope.testing/trunk/?rev=104110view=rev Thanks, Hanno ___ 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] Proposal: Determining packages which are in the ZTK
On Sep 18, 2009, at 11:53 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is from a note I sent yesterday to the ZTK steering group (Martijn, Christian, Jim, Stephan), proposing criteria for removing packages from the ZTK. Martijn has already updated the docs to reflect some of the criteria: I figured I would throw the rest out for discussion: - - If a ZTK package isn't used by at least Zope2 and Grok, it probably isn't getting the love needed to stay at an appropriate quality level to meet the ZTK goals. Given that the Zope2 developers have as an explicit goal removing dependencies on *any* zope.app.* package, I obviously believe that such packages should not be part of the ZTK. - - Any package which doesn't have real narrative documentation checked into its 'docs' subdirectory, or a commitment from a maintainer to create such docs, should be on probation. - - Any package which depends on a zope.* package which is *not* part of the ZTK should itself be removed from the ZTK. - - As a corollary, any package which depends on any other probationary package is automatically probationary itself. - - (A little more speculative) Any package which doesn't have one or more clearly-identified maintainers should be probationary. - - Packages which remain in the probationary status for a given period (three months? six?) should be removed from the ZTK. The overall goal here is to keep the ZTK as coherent as possible, and avoid bitrot by focusing on the packages which are in active use by more than one project. Sounds interesting. Do you happen to have a list of packages that would be affected by these rules? Gary ___ 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] Subversion externals versus mirroring
On Sep 15, 2009, at 4:56 AM, Wichert Akkerman wrote: In my experience distributed SCMs add bottlenecks to development that we currently do not have in the Zope community: with both our shared svn repository and distributed SCMs everyone can branch everything, but with distributed SCMs you have to ask a maintainer to merge any changes, something everyone can do directly right now. FWIW, this is some variable degree of wrong. 1) Everyone cannot merge changes right now: only developers that have commit privileges can do that. That's what you meant, I expect. 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Generally, I'd be surprised to learn that Bzr/Launchpad were alone in supporting this, but they are the only ones I can vouch for. For instance, I'm almost positive that github also allows you to have multiple committers to a single branch, though I don't remember the mechanism. Gary ___ 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] Subversion externals versus mirroring
On Sep 15, 2009, at 7:59 AM, Wichert Akkerman wrote: On 9/15/09 13:56 , Gary Poster wrote: 2) Our current arrangement, as well as many others, can be accomplished with a DVCS. Launchpad + Bzr definitely support this. You would have a Launchpad team of committers, with managed membership; and have the official branches owned and controlled by this team. Indeed, but most people do not do that. With our current setup once you get commit privileges you immediately have access to an entire world of things. With DVCS hosting systems that people use you have would have to request access for every single package. That is cumbersome and adds a lot of delay so people don't do that and fork instead. The end result is a lot more forks, half of which will probably never be merged back or seen by others. Perhaps that is the way other systems work; again, I can only vouch for Bzr/Launchpad, and your description is incorrect for us. With Bzr/Launchpad, a single time for each project, you would designate an appropriate committer team as having commit privileges for that project. Then, for each person that should be able to commit to all of the projects, you add them to that team. This is how we have our open-source Zope-friendly lazr.* packages set up. We have a single team for committers, which has privileges for all of our lazr.* packages. When a new person should be able to commit to all of the packages in the lazr.* effort, we just add them to that team. See, for instance, the trunk of lazr.delegates: https://code.launchpad.net/~lazr-developers/lazr.delegates/trunk . You simply need to be added to lazr-developers ( https://launchpad.net/~lazr-developers ) in order to commit to this and any of the other similarly- configured lazr.* projects. Gary ___ 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] ZTK test failures - zope.testing
On Sep 15, 2009, at 6:33 PM, Sidnei da Silva wrote: Hi Hanno, On Tue, Sep 15, 2009 at 6:42 PM, Hanno Schlichting ha...@hannosch.eu wrote: We are down to zero-build problems for the ZTK and just one test failure. This is in zope.testing in testrunner-layers-buff.txt. That smells like something Gary has touched recently. Meh, yes indeed--for all but one failure (see below). The Ubuntu one should be easy to fix. The Windows ones may be tied up with \n \r fun. It should be trivial too, though I'll need to get a Windows VM back up--or request aid from Sidnei. ;-) I'll address these issues tomorrow. However, there is a Windows failure that I don't think is on my plate, and I'd appreciate someone else looking at it: zope.testing-3.8.2- py2.4.egg\zope\testing\testrunner\testrunner-test-selection.txt, line 166, in testrunner-test-selection.txt . That's the very last one on http://dev.thehealthagency.com/buildbot/builders/ztk-win-py2.4%20slave-win-py2.4/builds/21/steps/test/logs/stdio . If someone else can address that last one, and I address the rest, we can have a new release. Gary ___ 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] Problem with zope.sendmail in Python = 2.5.1
On Sep 3, 2009, at 10:53 PM, Chris McDonough wrote: FWIW, we forked zope.sendmail a while back (with the intent of eventually merging these changes back upstream) as repoze.sendmail. It does not use any thread to do queue processing. Instead, a separate process can be run to handle queue processing. This is being actively maintained. http://repoze.org/viewcvs/repoze.sendmail/trunk/README.txt?rev=3688view=markup Thank you Chris. On the face of it, it sounds like it could be merged in with zope.sendmail very easily, if you have the same interfaces. The zope.sendmail package already advertises the ability to use an external process for processing queued mail, but that appears to be an aspect of the design and the interfaces rather than in the implementation. For this particular problem I faced, though, sticking with threads was easier for now. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 9:53 AM, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = Yeah, it'd be nice if buildout allowed that or some other syntax (like my-dev-package = *). ...Mmm, what Marius describes works for me, I believe. I've definitely used that trick and showed it to others, at least. Maybe it worked by mistake? /me wonders if he was doing something wrong, or if he remembersbut doesn't take the time to try it again right now. But to the bigger discussion here, I'm in the I don't like 0 camp, as I've said before. I like seeing the version number when I look at the trunk, which I do when I am doing different things than when I look at PyPI. I am skeptical of an argument that it helps prevent accidental releases. Is it not possible to make a '0' release? If it is possible, then you have to be just as careful. I think contemplating automation (e.g., release helpers that help you do the right thing, and warn you if it looks like you are doing a wrong one) is a better avenue in any case. Certainly the automation of setup.py sdist register upload is a thing of beauty in my eyes, and it could be improved. zest.releaser might be good, dunno. Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise), I have another issue. When you use externals/ develop-eggs to organize your dependencies during interlocked jobs like my recent efforts with zc.buildout/zc.recipe.testing/ z3c.recipe.filetemplate, and you want to set a minimum dependency for one or more of the develop-eggs, this breaks if your external has a version number of 0. The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. That said, I don't this is worth a big argument, or even a big discussion (or even this email? :-). If the Zope triumverate or whatever it is these days changes the release document, so be it. :-) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Sep 11, 2009, at 12:05 PM, Martijn Faassen wrote: Hey, Marius Gedminas wrote: On Fri, Sep 11, 2009 at 09:53:51AM -0400, Benji York wrote: On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). Right, but where does the superfluous come from? You'd have to change it to 0 anywa... Ah, I just realized that you do the version change on the branch/ tag, so trunk always stays at version 0. (I don't do that out of principle that tags ought not to be modified; and besides in other VCSes they can't be.) That's an interesting point. So if we were to adopt another version control system, the 0 policy wouldn't be much of a win anymore. Perhaps Gary can tell us whether this would work with bzr? bzr supports a classic definition of tags--identifying a specific revision. If it's of interest or help, I include the help text for the tag command at the end of my message. (The way we accomplish tagging in svn is by bringing our own semantics to certain names, of course. svn doesn't help us do that inherently, it's just convention. Because that's essentially a feature of being able to name stuff, you can do similar tricks with bzr--I'd make a branch for a tag if we were were following that pattern.) Gary $ bzr help tag Purpose: Create, remove or modify a tag naming a revision. Usage: bzr tag TAG_NAME Options: --force Replace existing tags. -v, --verbose Display more information. -h, --helpShow help message. -q, --quiet Only display errors and warnings. -d ARG, --directory=ARG Branch in which to place the tag. --usage Show usage message and options. -r ARG, --revision=ARG See help revisionspec for details. --delete Delete this tag rather than placing it. Description: Tags give human-meaningful names to revisions. Commands that take a -r (--revision) option can be given -rtag:X, where X is any previously created tag. Tags are stored in the branch. Tags are copied from one branch to another along when you branch, push, pull or merge. It is an error to give a tag name that already exists unless you pass --force, in which case the tag is moved to point to the new revision. To rename a tag (change the name but keep it on the same revsion), run ``bzr tag new-name -r tag:old-name`` and then ``bzr tag --delete oldname``. ___ 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] where is zc.zservertracelog 1.2.0?
Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0 but there is no download to be found! :-) Could whoever made the release add the download? Thanks Gary ___ 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 zc.zservertracelog 1.2.0?
On Sep 11, 2009, at 4:57 PM, Alexander J Smith wrote: On Fri, Sep 11, 2009 at 4:54 PM, Alexander J Smith a...@zope.com wrote: On Fri, Sep 11, 2009 at 4:44 PM, Marius Gedminas mar...@gedmin.as wrote: On Fri, Sep 11, 2009 at 03:51:30PM -0400, Gary Poster wrote: Hi. pypi advertises http://pypi.python.org/pypi/zc.zservertracelog/1.2.0 but there is no download to be found! :-) Could whoever made the release add the download? Is it important that the same person do it? In theory, since svn has tags for all releases, anybody could check out the right tag and do python setup.py sdist upload I believe you need to have PyPI privileges for that distribution in order to upload--an elite set of alexsmith, J1m, benji, achapman. :-) Sorry, my mistake! I'm fixing this right away. -- Alex Smith Software Engineer Zope Corporation Fixed :) Thank you very much Alex! :-) Gary ___ 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] Problem with zope.sendmail in Python = 2.5.1
Hi all. One of the contributors to the Launchpad project has identified a problem with zope.sendmail and thread changes in Python = 2.5.1. Here is his description: Description of the situation: Prior to Python 2.5.1, the atexit handlers were executed when the *main* thread exits. However,http://bugs.python.org/issue1566280 was then filed, the essence of which is that the atexit handlers could tear down cross-thread resources that were still in use by other threads. For this reason, the shutdown procedure was modified in Python 2.5.1 - now, when the main thread exits, it first makes a private call to threading._shutdown(), which waits until all non-daemon threads have exited, and *only then* proceeds to run the atexit handlers. Herein lies the problem. zope.sendmail.delivery.QueueProcessorThread attempts to use atexit to notify itself when it should shut down. However, the Python runtime = 2.5.1 will wait for the QueueProcessorThread to exit before it calls the atexit handlers! Potential solutions: (1) To gain behaviour most similar to earlier Python versions, an evil monkeypatch into Python internals like this: http://bazaar.launchpad.net/~maxb/zope3/launchpad-3.4-py2.5/revision/9works . (2) Make the QueueProcessorThread a daemon thread. It will be terminated without notification when the interpreter exits, but the current QueueProcessorThread does not attempt to ensure its queue is completely flushed before shutdown anyway, so that should not matter. I will attach a small Python demo program useful for illustrating and exploring the issue. You can see the bug report, and his demo program, here: https://bugs.edge.launchpad.net/zope3/+bug/413335 I wasn't going to send this until I had investigated this myself, but I have been taking too long and thought I'd at least send this out to see if anyone has any thoughts. Otherwise, I'll look into it ASAP and report back. Thanks Gary ___ 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] zc.buildout, substitution and templating
Shameless plug: try z3c.recipe.filetemplate.
http://pypi.python.org/pypi/z3c.recipe.filetemplate
. Sounds like it does what you want out of the box.
Gary
On Aug 27, 2009, at 9:14 AM, Encolpe Degoute wrote:
Hello,
These last days I was using collective.recipe.template and
gocept.recipe.env.
The second one just update options with os.environ.
Unix shell having their own substitution methods then '${' appearing
in
the .installed.cfg. It just blows if you try to rerun 'bin/buildout.
As zc.buildout is using something near string.template I patched
gocept.recipe.env to replace '$' by '$$' and
collective.recipe.template
to replace '$$' by '$'.
As _sub method in builout just split text around '$$' and join it
again
with '$$' we need to make the replacement with the result of this
method.
Is it the good way to deal with escaping data ?
Or is this a bug of zc.buildout ?
Regards,
--
Encolpe DEGOUTE
http://encolpe.wordpress.com/
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
___
Zope-Dev maillist - Zope-Dev@zope.org
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.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
Hi Tres
I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
unimportant to this email (I backported a change to trunk that was
discussed on the mailing list). It looks like you made a 3.5.7 with
the following change (omitting tests and the like).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver env['X-POST-QUERY_STRING'] =
env.pop('QUERY_STRING')
I can handle adjusting to this change, if it is appropriate, but my
concern is that it is not in trunk or any subsequent major release
(3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
to use my updated 3.5 release, which I had hoped would be a
conservative update, I have to change in a currently forward-
incompatible way.
What's the story here? Is 3.5.7 a brownbag that needs to have its
changes aborted in a subsequent release in that branch? Or are
those legitimate changes that need to be forward ported?
FWIW, we (Launchpad) also care about this case of a POST with other
pertinent, separate data in the query string, and the behavior you
implement here would be fine if it is necessary for Py 2.6 as your
comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string. I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access to
the query string on the request object, whether the method were get or
post or whatever else.
Gary
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 5:27 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
Hm. I sent this from the wrong account, so it didn't make it to the
zope-dev list. I'm also adding an additional bit of war story at the
end.
On Aug 24, 2009, at 11:16 AM, Gary Poster wrote:
Hi Tres
I made a 3.5.8 release of the zope.publisher 3.5 branch for a reason
unimportant to this email (I backported a change to trunk that was
discussed on the mailing list). It looks like you made a 3.5.7 with
the following change (omitting tests and the like).
98932tseaver # Python 2.6 notices QS-on-POST,
which breaks BBB for us.
98932tseaver # Suppress that.
98932tseaver if 'QUERY_STRING' in self._environ:
98932tseaver env = self._environ
98932tseaver env['X-POST-QUERY_STRING'] =
env.pop('QUERY_STRING')
I can handle adjusting to this change, if it is appropriate, but my
concern is that it is not in trunk or any subsequent major release
(3.6, 3.7, 3.8) of zope.publisher. Therefore, if I change my code
to use my updated 3.5 release, which I had hoped would be a
conservative update, I have to change in a currently forward-
incompatible way.
What's the story here? Is 3.5.7 a brownbag that needs to have its
changes aborted in a subsequent release in that branch? Or are
those legitimate changes that need to be forward ported?
FWIW, we (Launchpad) also care about this case of a POST with other
pertinent, separate data in the query string, and the behavior you
implement here would be fine if it is necessary for Py 2.6 as your
comment describes.
Also FWIW, this change breaks many of our forms that were explicitly
constructing form actions that included the current query string.
I'm
not sure how that could be avoided, although the fix might have been
simpler if there were always an X-ORIGINAL-QUERY_STRING or something
else.
If I were not already behind, I would investigate to understand the
Python 2.6 problem better and see what other frameworks are doing
here. I understand from conversations with other engineers that at
least some Django developers are accustomed to always having access
to
the query string on the request object, whether the method were get
or
post or whatever else.
It is *essential* for correct operation that QUERY_STRING values *not*
be admixed with POSTed form values. I don't really care how we
resolve
your issue, as long as we do not end up in a case where the values in
the query string get mingled into the form data: for instance, we
could
hand a QUERY_STRING-free copy of the environment to the
cgi.FieldStorage
machinery.
Whatever gets done needs to leave the existing test in place::
self.assertEqual(dict(request.form), dict(x='1', y='2'))
for a request whose QUERY_STRING was 'a=5b:int=6', but which posted
the
'x' and 'y' values.
I'm good with that.
My additional constraint would be that
self.assertEqual(request.get('QUERY_STRING'), 'a=5b:int=6')
for the same request. Hiding the QUERY_STRING causes us some
unpleasant and subtle functional test pain.
Passing a QUERY_STRING-free copy to cgi.FieldStorage as you suggest
seems like a good way to go to me.
Unless someone beats me to it or stops me, I'll plan to make this go
in trunk and in the 3.5 branch, and make a 3.5.9 release.
(If someone *were* to beat me to it, that would be awesome. I'm kinda
swamped.)
Thanks
Gary
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: Hi Tres Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases [...] If I were not already behind, I would investigate to understand the Python 2.6 problem better and see what other frameworks are doing here. I understand from conversations with other engineers that at least some Django developers are accustomed to always having access to the query string on the request object, whether the method were get or post or whatever else. It is *essential* for correct operation that QUERY_STRING values *not* be admixed with POSTed form values. I don't really care how we resolve your issue, as long as we do not end up in a case where the values in the query string get mingled into the form data: for instance, we could hand a QUERY_STRING-free copy of the environment to the cgi.FieldStorage machinery. As far as I understand, you are saying that it is essential that posted data and a query string should be separated for processing in python libraries e.g. FieldStorage or so. But this doesn't mean both values could not end in the request.form dict right? right, that's what he wants, and that's the pre-Py 2.6 behavior. Whatever gets done needs to leave the existing test in place:: self.assertEqual(dict(request.form), dict(x='1', y='2')) for a request whose QUERY_STRING was 'a=5b:int=6', but which posted the 'x' and 'y' values. Was this supported before your changes? Is this a new feature you decided to add? What's the reason for this? Can you point me to more infos? The constraint is an old behavior. The solution in 3.5.8 and 3.5.9 is a pretty big behavior change if you are paying attention to the query string during POSTs. Maybe http://bugs.python.org/issue1817 gives you the information you want? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] time.sleep in a boolean check in zope.publisher.http.HTTPRequest.supportsRetry?
On Aug 20, 2009, at 1:50 PM, Jim Fulton wrote: On Mon, Aug 17, 2009 at 1:43 PM, Gary Postergary.pos...@gmail.com wrote: Two teams here at Canonical just encountered the STAGGER_RETRIES behavior in http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/http.py?rev=101538view=auto . I don't see anything in tests or comments to explain it. Our guess is that it tries to put some breathing room around retries so that the chance of a conflict error might be reduced. Yup, although I think it's misguided in this case. With conflicts, there's always a winner, so it makes sense to try again right away. In one of our tests setting STAGGER_RETRIES to False reduced a test run from almost 9 minutes to about 1 minute (see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/401586) . We have papered this over in our test suite to no ill effect, giving speed advantages. We wonder if we should remove the behavior entirely, even in production. I think so. 1) Why should the time.sleep go into supportsRetry rather than retry? it seems really odd to have it in the method that returns a boolean, rather than the one that does the work. Yup. 2) Can someone give some background for this code? Can they give examples of it actually helping anything? I doubt it. We'd like to improve this, minimally by adding some explanatory comments, and maybe by changing, moving, or removing this code. Let's just remove it. Cool, I'll do it tonight or tomorrow (have to run right now). Thank you very much! Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] time.sleep in a boolean check in zope.publisher.http.HTTPRequest.supportsRetry?
Two teams here at Canonical just encountered the STAGGER_RETRIES behavior in http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/http.py?rev=101538view=auto . I don't see anything in tests or comments to explain it. Our guess is that it tries to put some breathing room around retries so that the chance of a conflict error might be reduced. In one of our tests setting STAGGER_RETRIES to False reduced a test run from almost 9 minutes to about 1 minute (see https://bugs.edge.launchpad.net/launchpad-foundations/+bug/401586) . We have papered this over in our test suite to no ill effect, giving speed advantages. We wonder if we should remove the behavior entirely, even in production. 1) Why should the time.sleep go into supportsRetry rather than retry? it seems really odd to have it in the method that returns a boolean, rather than the one that does the work. 2) Can someone give some background for this code? Can they give examples of it actually helping anything? We'd like to improve this, minimally by adding some explanatory comments, and maybe by changing, moving, or removing this code. (If anyone tries to do an annotate on this, you'll see Jim checked this in back at the dawns of time in rev 8532. On IRC, he didn't recognize this code on a quick look, so he thinks someone else might be more familiar with this.) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.async: cron replacement?
On Jun 24, 2009, at 1:19 PM, Reinout van Rees wrote: Hi all, In messages like http://www.mail-archive.com/zope3-...@zope.org/msg05964.html , zc.async is mentioned as the solution for cron-like functionality in zope. Effectively you would not need zope2's clockserver. Reading zc.async's docs, I cannot find how to do a given task regularly. For example a weekly pack. Or a daily call of one method that archives older items. That sort of stuff. Many things can be handled by cronjobs, but you tend to get a lot of them. And you don't want to embed the password everywhere. Anyway: I cannot find the word cron anywhere in the zc.async source. Or repetitive or regular. Is zc.async not intended for this kind of usage? Hi Reinout. zc.async can be used to do cron-like activities by starting a job, to be performed after a certain time, that has a callback that reschedules another job when desired. This has the advantage over cron-like behavior because it does not reschedule until the first job is done. Other zc.async competitors have cron implemented more directly, but I found it to be very easy and flexible to do what I wanted using the zc.async approach. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] tabs in the source
On Jun 22, 2009, at 1:16 PM, Adam GROSZER wrote: Hello, Maybe it's time for an svn commit police squad? 22 .py files have tabs... and I grepped only zope.* packages. FWIW, to state the probably obvious, other projects handle this with varying degrees of increased control. Some require one or more reviews before a commit (Launchpad and others support this--github maybe? I forget). Others require certain quality tests to pass before a branch is merged (I'm familiar with PQM or the upcoming Tarmac combined with bzr, but there are many many other posibilities, I'm sure). Others use buildbot for various tests, using the social embarrassment vector. Launchpad developers have ongoing experiments in this regard, currently combining all of the approaches. I've found them much better than commit police squads both in terms of what they catch and what kind of interaction they encourage. Jono Lange has a nice talk about code review, FWIW, with links to more (like Guido's old Mondrian video). http://mumak.net/stuff/your-code-sucks.html Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Feature Request] add 'extensions' option to z3c.recipe.sphinxdoc
Hi Markus. Stephan Richter and Paul Cardune are the people I would expect to manage this package. I expect they'll get back to you soonish. On freenode #zope3-dev they are srichter and pcardune, IIRC. The feature and the diff look reasonable to me. Normally we want tests in our diffs, but this package doesn't have them yet, so I don't see why it should block this contribution. FWIW, I did notice a trivial issue: a spelling error in the CHANGES: seperated - separated. Thanks! Gary On Apr 28, 2009, at 9:25 AM, markus korn wrote: I'm not familiar with your process of implementing new features, but the attached patch adds such option to z3c.recipe.sphinxdoc, comments welcome. Markus add_extensions_option .diff___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zc.buildout template recipes: concerns with [z3c|collective].recipe.template and other issues
I'm concerned about the state of the zc.buildout template recipes. I want one. I want some one-off files, specific to a certain project, for which writing a standalone recipe feels very heavy. Here are the template recipes I found: collective.recipe.template (Wichert Akkerman) iw.recipe.template (Ingeniweb) inquant.recipe.textfile (Stefan Eletzhofer) z3c.recipe.template (Uli Fouquet) buildout_script (Nathan Yergler) z3c.recipe.filetemplate (Philipp von Weitershausen) First, on the basis of this list, it strikes me that a lot of people want this functionality. Putting template support into zc.buildout itself would be nice. I envision some APIs (like the ones in easy_install.py that zc.recipe.egg uses) that other recipes could use easily. I would even want recipes like the zc.recipe.egg script recipe to allow specifying initialization code by identifying a template (i.e., ``initialization_template = buildout_templates/foo``, which would parse the given template and insert the code the same way the ``initialization`` parameter works). Second, there's no clear winner at the moment. I happened to find z3c.recipe.template, buildout_script, and z3c.recipe.filetemplate first. On the basis of those three, and the comments that z3c.recipe.template made about collective.recipe.template, iw.recipe.template, and inquant.recipe.textfile, I decided to settle on z3c.recipe.template to be the package to which I would contribute. It has tests, a variable substitution approach that seems to work well with buildout, and recent development activity. However, on starting to hack on its documentation to sketch the changes I wanted, I gradually realized that this was a fork of collective.recipe.template. Since collective.recipe.template is listed as BSD in setup.py (though I saw no explicit licensing otherwise), placing z3c.recipe.template in the zope.org ZPL-only repository is problematic. Since I don't find the prospect of creating yet another template recipe attractive, and Philipp's z3c.recipe.filetemplate looks like it can take my new features while maintaining backwards compatibility, I'll try that next, I suppose. But meanwhile, I'm concerned about the state of z3c.recipe.template. IMO, Uli and Wichert should try to reconcile the licensing and forking issues (with Uli taking the lead in those discussions, ideally, since he is the one who forked). z3c.recipe.template should be removed from the zope.org repository, unless/until the licensing story is cleaned up. And maybe we can start to settle on a common template approach soon. This should be a problem that is solved for buildout canonically, IMO. I'll be happy to try and see if my features are generally interesting, once I make them. (Note: I could write about this on the distutils list but I'm not already subscribed there, and I suspect I have a better chance of catching some authors of the pertinent recipes over here, and some of this is about the zope.org repo.) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
On Apr 15, 2009, at 11:28 AM, Lennart Regebro wrote: Here are a list of things I have seen that you may mean when you say Zope 3. I'm sure I missed several: 1. Whatever is included in the Zope 3 tgz that you download. 2. All the packages included in the Zope 3 KGS. (Should be the same as 1, if I understand correctly.) 3. 1 or 2 minus the ZMI. 4. The zope.app.publication publisher. 5. A loose set of packages starting with zope.*, zc.* and z3c.* 6. A strictly defined (by the Zope Toolkit KGS) set of packages starting with zope.*, zc.* and z3c.* that is central and common to Zope 3 in the sense of 1 or 2, and also Grok and Zope 2. 7. Technologies that you use when you develop with the packages in 5 and 6. I propose that the name Zope 3 applies *only* to 1 and 2. If future versions of 1 or 2 gets released without the ZMI (as discussed in other threads), then of course 1, 2 and 3 is the same. Opinions? I've been away on a vacation of sorts, and find myself happy to not have been around for this firestorm. A few observations. - I very much agree with Lennart's observation that the definition of Zope 3 is not clear. - It may have been a mistake to use the name Zope 3, but it is done now, and done a *long* time ago. Trying to outright kill it feels like thrashing. - Moreover, because *we* don't know what Zope 3 means, I'm afraid users outside viewers are going to easily misinterpret any kind of message framed in the terms of Zope 3's death or abandonment or whatever.How are they supposed to know what it means? I was concerned about Tim Hoffman's statement in the long who wants to maintain... thread: It seems from all the discussion of late that we might of chosen a architectural dead end (though I don't think so). We're not declaring the Zope 3 libraries (toolkit, whatever, bah) a dead end; far from it. But how easy it is to make a sound bite from this discussion into basically that message? Zope 3: architectural dead end. I don't care for that, myself, nor do I find it accurate. This message seems like a reasonable start to me: Zope 3 has become focused on supporting frameworks and applications, rather than trying to be one itself. It is now called the Zope Toolkit. Parts of it are used by Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and frameworks. That message implies two things to me. First, to start with, this is just a rename. Zope 3, as defined by the KGS, becomes the Zope Toolkit. Second, the Zope Toolkit is about supporting other frameworks. That means that it is reasonable to expect that the packages and the parts of packages that were about the ZMI will quite possibly die a typical open source death of not enough people caring anymore. I don't think trying to guess which parts or packages will die is a particularly useful exercise. The community will support what the community supports...as usual. This is open source. You're gambling that enough other people will be there with you to make it worthwhile, and you may be required to step up with money or talent or energy to make that happen. So, again, in sum, I propose that this discussion should simply be reduced to a rename to start with: Zope 3, as defined by the KGS - Zope Toolkit. The software switch that this name change implies has started quite some time ago, with the eggification, and will continue in its natural and usual open-source course. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Apr 6, 2009, at 9:28 AM, Chris Withers wrote: Gary Poster wrote: Sadly, I suspect none of the tools are as advanced as TortoiseSVN. Which is a real shame :-( Perforce maybe? ;-) Fair enough that bzr didn't take your fancy, but FWIW, did you try TortoiseBzr? That has received love relatively recently. I'm looking at this: http://bazaar-vcs.org/TortoiseBzr/Screenshots Where's the visual diff? Where's the interactive log of revisions? Where's the repository browser? FWIW, I don't know if TortoiseBzr has this. I'd be surprised if it didn't have these, especially the first two. It would be cool if someone with easy access to Windows were to check this out. Otherwise, I'll give it a try eventually and report back myself. (If it has these features, I'll try to figure out someone to ask to get that page updated.) Does it work the same on Windows, Ubuntu and Mac OS? (I assume you mean bzr vs.svn, rather than TortoiseBzr vs. TortoiseSvn; AFAICT, Tortoise* is Windows only.) Well, the EOL problem has been the only bzr kicker there. That was just addressed, spurred most recently in part because of the concerns from the Zope community; I don't know if it is in 1.13 or the upcoming 1.14. Other than that, I think bzr cares a fair amount about Windows (and certainly about Ubuntu and Mac). http://tortoisesvn.net/image/tid/13 gives a fair idea of the kinds of things I'd need to feel compelled to change... Right. Looks nice enough. Gary___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Apr 2, 2009, at 7:35 PM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gary Poster wrote: I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition. [snip saying I'll do it later, and apology for misunderstanding of Foundation membership] The foundation members are a *subset* of all committers, with sponsoring companies added on. There are under 50 nominated members (formerly committer members, whereas there are something like 375 committers. Any decision to move the repository will need to be formally made by the foundation (via its board), but that would only happen if the consensus of the members and the wider community were clearly in favor of a move. Good to know, thank you. Off to write the email... Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Constant values defined in interfaces
On Apr 3, 2009, at 12:35 PM, Chris Rossi wrote: Hello, Hi Chris. I was wondering if the Zope collective had given any consideration to allowing constants to be defined in interfaces. To be clear, these are constant values that make up the protocol defined by the interface. ... FWIW, interfaces.py is often regarded as a contract itself. A current best practice is to define constants and exceptions in that file, and import them from the module. If this hasn't been done yet, I can envision doing something like: from zope.interface import Constant class IHttpResponse(Interface): Models an HTTP 1.1 response. HTTP_OK = Constant(200 Ok, An HTTP Ok response.) HTTP_NOT_FOUND = Constant(404 Not Found, An HTTP Not Found response) status = Attribute(HTTP status code for this response.) How would that be a win for you (or anybody else) over just putting the constant in the interfaces module? If it is in the interface, that implies we need to implement it someplace--the constant will be defined in the interface and in the implementation? Or we would offer automation to copy the values over from the interface to objects that implement the interface? Using descriptors, the results could be both static and immutable. Mostly static and immutable, anyway. :-) In Python, there's almost always a way around absolutes like that unless you are working with something in which the constraint has been coded in C. I don't find enforcing a constant's immutability in any way other than relying on a programmer's good sense to be particularly valuable. I have sympathy for enterprise-y concerns, in which you have some belt- and-suspenders--we use security proxies for that kind of thing, and appreciate them despite their added pain--but I don't see how a programmer might forget to not overwrite an ALL_CAPS constant. And finally, this Constant constructor would control the interface, not the implementation, so you'd have to do the static/immutable things elsewhere. So, I'm -1 on Constant unless someone gives a convincing reason why it is preferable to putting constants in the module, in which case I will suddenly have a polar shift to +0. :-) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Constant values defined in interfaces
On Apr 3, 2009, at 7:21 PM, Wichert Akkerman wrote: This looks like a poor man's enum. I'ld prefer to have a proper enum like thing. Seems a little different to me. For what it is worth, though, if you do want an enum in zope.schema, Canonical has lazr.enum: http://pypi.python.org/pypi/lazr.enum . Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Source Code Repository
On Apr 2, 2009, at 1:31 PM, Chris Withers wrote: Hey All, ... The other option would be to follow Python and move to Mercurial, but that has the same problems for me as with Bzr (no decent gui tools, less mature, etc) although it's a toolset I'll have to learn at some point anyway... I'd like to report back on the progress that Bzr/Launchpad has made addressing concerns we heard since I last brought up Canonical's offer to host the code and contribute commercial support for the transition. When I do that, I'll do it on zope-dev, assuming that Tres' statement in this thread that we should discuss there is authoritative. (I thought the people on Foundations were the superset of people who commit to the repo, but I guess I was mistaken. Sorry for my misunderstanding.) However, I just got back from a long trip, and I'm going to spend some time with my family. I'll write something up to zope-dev tomorrow. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please use launchpad bugtracking/blueprints more
On Mar 25, 2009, at 11:52 AM, Sidnei da Silva wrote: Hi Martijn, On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen faas...@startifact.com wrote: One question is what launchpad project we should use. The current launchpad is for Zope 3. The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most. It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at: https://launchpad.net/chameleon-template-engine I can help setting up this structure, if needed. I agree with Sidnei. Another example is the lazr projects (https://launchpad.net/lazr ). To be clear, making an umbrella project like this does need someone with admin rights in lp, so it will need help if it is desired. :-) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] PyCon?
On Mar 24, 2009, at 6:12 AM, Chris Withers wrote: Hey All, Who's around at PyCon? If so, when/where are we meeting up? Arriving Thursday evening, leaving following Thursday afternoon. I'm starting at the Hyatt, going to the Crowne Plaza on Monday. Email is maybe the best public way to get in touch with me, though I'm happy to share cell phone/skype info privately. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Please use launchpad bugtracking/blueprints more
On Mar 25, 2009, at 2:21 PM, Martijn Faassen wrote: Sidnei da Silva wrote: Hi Martijn, On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen faas...@startifact.com wrote: One question is what launchpad project we should use. The current launchpad is for Zope 3. The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most. It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at: Why would the steering group be a project as part of the Zope Framework? The steering group isn't a project? I'm all for setting something up, but I'm still not clear on what you'd set up. A Zope Framework project group with what inside? My take would be the following. It's probably contentious. - The current zope3 project is regarded as a project for the aggregation of the pieces into the old tgz and the old mgmt UI. This should be clarified on the project page. - There is a new Zope Framework (I would prefer Zope Libraries myself, but let's not start that again ;-) ) umbrella project, controlled by a new Zope Framework team. - There are multiple zope.* (and z3c.* and whatever) library projects. They are part of the umbrella project (if so desired by the pertinent parties). - The current zope3 project should be considered part of the Zope Framework *at least for now* because it has legacy information. If someone reassigns the bugs and blueprints and so on to the pertinent library projects (or to the Zope Framework), zope3 could no longer be part of the Zope Framework umbrella project, if desired. That's work, though, so I'd be inclined to see if it happens and meanwhile be happy to take the zope3 project in as legacy. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 10:55 PM, Martin Aspeli wrote: Gary Poster wrote: Yes, +1. Thank you. I was about to write to your other message that this was quite possibly the only 3.8 dependency. Cool. Committed. If we do that, then we can let plone.relations depend on zc.relationship 1.1.1 explicitly and have support for both ZODB versions, which would be nice. Sounds great. Would you like access to the PyPI zc.relationship record so you can upload the new version? If so, are you optilude there? That'd be great, yeah. Or else, if you want to tag a release from the 1.1 branch, that should be safe (and even less work for me :-) OK. I changed setup to fix the tests with the most recent packages, made a tag and release, and gave you access to the PyPI package just in case. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 8:39 AM, Martin Aspeli wrote: Gary Poster wrote: On Mar 16, 2009, at 4:02 AM, Martin Aspeli wrote: Hi, I *think* this is a bug in zc.relationship, but I'm not quite sure. I'm using ZODB3 3.8.1 (to get BLOB support) and trying to install plone.app.relations, which depends on zc.relationship 1.0.2. In particular, it subclasses zc.relationship.shared.Container, and stores a zc.relationship.index.Index object in self.relationIndex. Now, the __init__ of zc.relationship.index.Index, which derives from Persistent, contains the code below. In self._relTools and and self._attrs, there are a pile of modules, types and functions being stored. I think these are causing the ZODB to barf. Interestingly, with whatever version of ZODB that comes with Zope 2.10 (3.7?), there's no problem. Any ideas how to work around this, or even why it's a problem in one version of the ZODB but not another? No idea yet. What's the barf's traceback? Mmmm... it seems that zc.relationship 1.1 fixes the issue, but has some other problems (an undefined variable minValues or similar - I haven't got a build with this version in it right now); OK. 2.0dev seems better, albeit a bit scary at pre-alpha. zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. You guys are the main clients for zc.relationship at this point, I suspect. As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 9:19 AM, Martin Aspeli wrote: Hi Gary, zc.relationship 2.0 trunk is now essentially a wrapping of zc.relation code for backwards compatibility. I see. But 2.0dev on pypi isn't? What's the story behind zc.relation and the evolution of zc.relationship? Briefly, I wanted a package that only included the bit I used, the index (in zc.relation, the catalog). I abstracted it, made sure that zc.relation had 100% test coverage, and changed the names and the API in a backwards incompatible way. I also added a bunch of new features, like a transitive index for hierarchies. See http://pypi.python.org/pypi/zc.relation#changes for details. zc.relationship trunk then depended on zc.relation, and existed to provide backwards compatibility while not forcing me to maintain two versions of the same codebase. The upgrade path that the zc.relation PyPI doc describes from a zc.relationship index to a zc.relation index has been used in production, IIRC, but it requires zc.relationship trunk. I would be quite happy to release zc.relationship trunk as 2.0, if it helped you: it was used in production. If the ZODB 3.8-only issue is not a show-stopper then that's a good approach, and hopefully pretty easy for everyone. You guys are the main clients for zc.relationship at this point, I suspect. Possibly, yes. ;-) As I see it, your relatively reasonable options are these: - MOST WORK: Move the plone.relation code to depend on zc.relation. There is an upgrade path for the old indexes. You would need to copy over the old zc.relationship relationship containers to the Plone package. IIRC, Alec's tests of those bits were good, and you could just keep the bits from zc.relationship you needed. ZODB module path issues in legacy databases would be among the more annoying bits of this approach, though we all know the usual solutions there. I think we'd need Alec to find the time to do this if it's to happen, but it does sound like the better option. Perfect world, sure. - LESS WORK: See how zc.relationship trunk works for you. If it makes the code happy, I can release it or help you to do so. It's certainly been sitting around long enough. Then at least you are sitting (indirectly) on top of zc.relation, the package that (for instance) Martijn F.'s Grok work exercises. This would be my preferred compromise between effort and migration. The problem here is that it probably does depend on ZODB 3.8, and I'd rather not make the zc.relation code support the older spellings, so that's probably out for you unless you want to make a concrete counter-proposal in this regard. Well, having a version that only works with ZODB 3.8 isn't *terrible*, it's just annoying. If and when Plone actually ships with five.intid and plone.relations, it'll be on ZODB 3.8 anyway. It's just a bit more work for people wanting to use it. Gotcha. Your choice. FWIW, this was the path I intended/hoped you guys would follow when I did the work to make zc.relationship sit on top of zc.relation. - LEAST WORK: Figure out what's wrong with zc.relationship 1.1. What you described sounds trivial to fix, and I don't have any ethical issues over only supporting the most recent release of the 1.x line, so I don't want to think about the earlier releases. I suspect this is what you want. We can make a 1.1.1 release and you can move on. Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 10:21 AM, Martin Aspeli wrote: Hi Gary, Thanks for being so helpful! Happy to. What's the difference between 1.1.1 and 2.0dev on pypi? I intended that 1.1.1 would simply make the absolutely minimal changes necessary for you to be able to use the 1.1 branch. It would not have any of the 2.x changes at all. But we're saying that 2.0dev is a very different beast to the trunk that could eventually become 2.0, right? 2.0dev doesn't have a zc.relation dependency, for example. Yes. They are related, of course, but practically significantly different. I'm not sure what else there may be in 2.0dev that's useful, of course. Honestly, I'm not sure about the alpha any more either, though IIRC I did do a reasonable job on the change logs, so we could figure it out. I think we need to hear from Alec on what makes most sense for plone.relations. I care pretty much only about the plone.relations API, so I'm sure either of your three options could work. However, I have no idea how hard it'd be in practice to move closer to zc.relation. Sure. My hope is that switching to zc.relationship trunk (2.0) would be a drop-in change. Otherwise, 1.1(.1) definitely should be (with whatever necessary bug fixes). Let me know how I can help, once you all decide what direction you want to go. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setting missing minimum version in setup.py
On Mar 16, 2009, at 12:05 PM, Dan Korostelev wrote: 2009/3/16 Martijn Faassen faas...@startifact.com: There is a compromise I am willing to take. If package zope.bar depends on a *new feature* or *feature change* in zope.foo 1.3.x, then it should specify the version. In other words specifying open restrictions on the major version levels is okay, but never on the bug fix level. (I just hope this does not bite us later. ;-) Yes, I was thinking in this direction too. I can see this as more of an issue with bug fixes than with feature changes. This means that requirements can only say zope.foo = x.y, and never zope.foo = x.y.z. What do people think? That looks sane, so I'm +1 :) Also +1 Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.relationship - can't pickle module objects
On Mar 16, 2009, at 1:20 PM, Martin Aspeli wrote: Martin Aspeli wrote: Gary Poster wrote: Hopefully. Do we know that zc.relationship 1.1 works with both ZODB versions? That would be a significant point of its existence, so I certainly hope so. I'm 80%+ confident that it does, and would regard not supporting 3.7 as a bug that I'd be willing to fix. Right... so I've just fixed the errors Pyflakes found with zc.relationship 1.1 branch. This now works reliably for my ZODB 3.8.1 build. However, it won't install in my ZODB 3.7 environment, because of this line in setup.py: 'ZODB3 = 3.8dev', Was that an intentional minimum? Okay... so, if we remove that restriction, and add the following monkey patch to (which is already in plone.relations) to __init__.py, then this works on ZODB 3.7 with Zope 2.10, and the tests pass (save for cosmetic doctest failures on 3.7 which are easy to fix): # A tiny monkey patch due to some re-organization of future BTree modules try: from BTrees.OOBTree import BTree except ImportError: import BTrees.OOBTree import BTrees.IOBTree import BTrees.OIBTree import BTrees.IIBTree import BTrees.IFBTree BTrees.OOBTree.BTree = BTrees.OOBTree.OOBTree BTrees.OOBTree.Set = BTrees.OOBTree.OOSet BTrees.OOBTree.Bucket = BTrees.OOBTree.OOBucket BTrees.OOBTree.TreeSet = BTrees.OOBTree.OOTreeSet BTrees.IOBTree.BTree = BTrees.IOBTree.IOBTree BTrees.IOBTree.Set = BTrees.IOBTree.IOSet BTrees.IOBTree.Bucket = BTrees.IOBTree.IOBucket BTrees.IOBTree.TreeSet = BTrees.IOBTree.IOTreeSet BTrees.OIBTree.BTree = BTrees.OIBTree.OIBTree BTrees.OIBTree.Set = BTrees.OIBTree.OISet BTrees.OIBTree.Bucket = BTrees.OIBTree.OIBucket BTrees.OIBTree.TreeSet = BTrees.OIBTree.OITreeSet BTrees.IIBTree.BTree = BTrees.IIBTree.IIBTree BTrees.IIBTree.Set = BTrees.IIBTree.IISet BTrees.IIBTree.Bucket = BTrees.IIBTree.IIBucket BTrees.IIBTree.TreeSet = BTrees.IIBTree.IITreeSet BTrees.IFBTree.BTree = BTrees.IFBTree.IFBTree BTrees.IFBTree.Set = BTrees.IFBTree.IFSet BTrees.IFBTree.Bucket = BTrees.IFBTree.IFBucket BTrees.IFBTree.TreeSet = BTrees.IFBTree.IFTreeSet Shall I just check that in + the removal of the minimum version pin? Yes, +1. Thank you. I was about to write to your other message that this was quite possibly the only 3.8 dependency. If we do that, then we can let plone.relations depend on zc.relationship 1.1.1 explicitly and have support for both ZODB versions, which would be nice. Sounds great. Would you like access to the PyPI zc.relationship record so you can upload the new version? If so, are you optilude there? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python3 and attribute annotations.
On Mar 9, 2009, at 5:20 PM, Dan Korostelev wrote: Hi zope developers! As you may know, python 3 introduced the concept of annotations for callable objects. That annotations store information about arguments and return values, which is kinda nice language feature that will allow us to do interesting things. But there's a problem: those annotations will be stored in object's __annotations__ attribute, which is also used by zope.annotation's AttributeAnnotation implementation, so they will conflict. I think that it's a good time now to start thinking about problems like this, because there's a lot of time before zope will be used in python 3.0, so we can prepare to move without much problems. So, I propose to change annotation storage attribute to __zope_annotation__ and make AttributeAnnotation adapter automatically migrate data from __annotations__ to __zope_annotations__. I think that adding zope to the attribute name will avoid any name clashes in future. I'd like to hear about problems that this change can possibly introduce (__slots__, security proxies, etc.) and maybe some more community ideas on that. Hi Dan. Thanks for bringing this up. If we do make changes for this purpose, I'd like to no longer use the __*__ pattern. When Zope 3 used the pattern initially, Python was not clear on its usage. Since then, it has clearly stated that the language claims __*__. While your proposal (__zope_*__) would almost certainly avoid a clash, I'd prefer to stick to the letter of the (new) law. I'd prefer _z_* or _zope_* or _z_*__ or some other variation. (The ZODB usues _p_*, of course; I am inclined to _z_* because of the parallel and because it is short.) (If you are interested in the Python waffle when Zope 3 was written and the current language reference/PEP 8 , see my blog post this from February: http://codesinger.blogspot.com/2009/02/dont-use-in-python-unless-you-are.html . It may come off more strongly than it should, but I still find the point to be a good one.) Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
On Mar 6, 2009, at 9:50 AM, Martijn Faassen wrote: Hi there, Thanks Gary for sketching our the zc.async usecase. Note that zc.async isn't in the Zope Framework at this point in time so it wouldn't be directly affected by this policy, but it's still a useful usecase of course. Right, that was the intent. ... * we are going to work at getting rid of the zope.app.testing extra by distributing its facilities into individual zope.* packages. Hopefully we can get a clear consensus on this one from the people who object to the general policy. +1 * if you think a new extra dependency is needed in a Zope Framework package, and you're not just moving stuff between packages but actually developing new code, bring it up on zope-dev so we can at least consider alternatives. Perhaps a better home can be found for this code. Fair enough. * on a case-by-case basis we can consider removing extra dependencies for particular Zope Framework packages, just like what we're doing right now for zope.component. We'll discuss that whenever needed. I'll of course be biased in favor of such removal, but I can be convinced otherwise. Fair enough. Thanks Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
On Mar 6, 2009, at 4:30 PM, Dan Korostelev wrote: 2009/3/6 Tres Seaver tsea...@palladion.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hey, Laurence Rowe wrote: [snip] It seems there is a 'tests_require' One reason that isn't used is that apparently there is no way for us to dig up this information in the way our test runner needs, unlike extras requires. If the testrunner would require 'eggtestinfo', and introspect the extra data it records, this wouldn't be true any longer. +1. Though, if that eggtestinfo package is really tiny, as I believe it is, we could just copy it into the testrunner not to create extra dependencies. (http://pypi.python.org/pypi/eggtestinfo) I skimmed the docs, but they were written generically, so I couldn't confirm: Tres, is this the thing that lets you run ``setup.py test`` against zope.testing, if you configure it properly? The last example seemed like that was it. If so, +1 on getting this into zope.testing, or at least this pattern into our standard ways of writing tests. IME, that's what non-Zope Python developers expect (as Tres has argued before). It's a small thing, but would get the non-Zope Python developer's experience off on the right foot. Tres, you've obviously done the research here to know: can we easily change zope.testing to make that story work? Or would you say that eggtestinfo is still a better/easier way to go about it, at least for now? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Standard request/response API
On Mar 1, 2009, at 1:00 PM, Jim Fulton wrote: There's been some discussion recently about separating the interfaces in zope.publisher from the implementations to facilitate other implementations. I think it would be great to standardize request and response APIs. I'd love to see this extend beyond the Zope community. I believe that there have been some moves to try to do this at the WSGI level, although I haven't kept up with the discussion. Speaking for myself, I'd be happy to change my code to comform to a python-standard request API assuming that it had enough in it to adapt it to existing APIs. This might be an excellent project for PyCon. Hey. I have some other projects to work on there as well, but I'll be at PyCon, and am interested in helping on this (specifically the WebOb idea already discussed). Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope 3 app server dying? (was Re: the Zope Framework project)
On Mar 5, 2009, at 6:38 AM, Hermann Himmelbauer wrote: And I am personally interested if the Zope 3 app server is something that's dying in favour for other projects (Plone/Grok) or is actively used. Not clear on what you mean by the app server. If you mean zope.publisher, no, I don't think it is dying. The proposals to learn from repoze's approach, and hopefully integrate with WebOb, mean that this is alive and kicking. Also, to varying degrees, some medium-to-big companies are sitting on top of it, and these companies IME tend to have big code bases that tend to change decisions like this slowly. Also, I'm pretty sure Grok also sits on top of much of the publisher machinery. On the other hand, I personally have the impression that the basic Zope 3 ZMI is pretty much dying or dead. Grok and Plone are the only ones innovating in that space (in extremely different ways, of course), as far as I can tell. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
On Mar 5, 2009, at 1:43 PM, Martijn Faassen wrote: Hi there, I know opinions are divergent about 'extra' dependencies in setup.py. These ar dependencies that effectively make a single project with a single dependency structure into a number of virtual packages that each can have a separate list of dependencies. Such a virtual package that we're currently getting rid of is zope.component[zcml]. ... Opinions? I disagree with the blanket statement. I do lean towards not having the extras for the test package only. I'm fine with the policy If you want zope.testing for your tests, then keep it as a dependency for the package. But I like to have the option of extras for testing additional setups. zc.async uses extras so that the main tests show the functionality as a Python library; another level adds more Zope dependencies, with associated tests; and the last level adds the most. I could have divided these up into multiple teensy-weensy packages but I didn't really want to. It seemed like overkill. I've also done this in other circumstances in which code could use zope.proxy/zope.security, but I really didn't want to add the hard dependency. The tests to show that proxies were handled correctly were only part of the extras. Dividing this package also would have made no sense--it was already just a few small classes. For a package as central as zope.component, I think the pattern Tres is pursuing--dividing everything up--makes sense. For most other packages, I personally feel that there are circumstances in which extras are a useful tool. I do wonder if there's a ``setup.py test`` spelling for testing these extras though. If there were not, I'd find that a good argument against the extras pattern, at least for core Zope packages. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Review of zc.dict tlotze-blist branch
On Mar 4, 2009, at 2:20 AM, Thomas Lotze wrote: Gary Poster gary.pos...@gmail.com schrieb: Index: src/zc/dict/configure.zcml === --- src/zc/dict/configure.zcml (.../trunk) (revision 0) +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) (revision 97211) @@ -0,0 +1,5 @@ +configure xmlns=http://namespaces.zope.org/zope; + + include package=.generations / + +/configure configure.zcml has a semantic of always include. Because the generations code may not work for many people (as we've discussed before, and see comment in evolve test below), I'd prefer that the generations code have a semantic of optionally include. Therefore, I suggest you rename this to generations.zcml or something like that. Wouldn't it be simpler to just remove this file as it does nothing but include the configure.zcml of a sub-package? Using the generations configuration would then read include package=zc.dict.generations / instead of include package=zc.dict file=generations.zcml / which wouldn't be for the worse either IMO. +1, good idea Also as mentioned before on the Zope list, until this API is deprecated in favor of one that encourages more granular changes, the change to blist only really helps the story for adding new items to an ordered dict. The Plone IExplicitOrdering interface looks reasonable, and could really take advantage of the blist characteristics. I do have that on my to-do list. Do you think we should add some comment about this to the code? I think the current performance characteristics are important to note somewhere, at least. Even CHANGES would be sufficient. Thanks, Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 7:35 AM, Martijn Pieters wrote: ... And so far I haven't heard any better ideas than what Martijn is proposing (no, leaving the status quo, deny there is a problem and steer by majority is not a counter proposal in my view). It may be that the idea needs some tweaking, but that's just details. Would it be possible to focus this discussion around clearer lines? Create counter proposals if you have to ... I'm surprised my proposal didn't generate any replies, and can only assume that it is because it created the silence of everyone quietly saying Whaaa? :-) My mild counter proposal was this. - The ZF formally institutes an easy way for people to start Zope projects - Hopefully, Martijn F. starts something like the project he described - Hopefully, people follow it. In other words, I suppose, Just Do It. I don't think Martijn, nor anyone else who has been part of the community long enough to be on the ZF, needs the entire community to bless his idea to try to move forward--they need just an absence of a veto for the use of the chosen name, as I proposed more concretely in the original email. I think that incorporates some of the more laissez-faire advocates are arguing for: someone else can also start their own counter project, if desired. Maybe they won't, but they can. And this freedom could allow us to escape the need to feel that everyone has to agree about this. Beyond that, I didn't say my other smaller thought, which was that I think the KGS should ideally be looser and more flexible than what Martijn described. If you have a project that wants in on the KGS, great, you can add it. Institute a nightly KGS for an upcoming release (and maybe the most recent release). It stays around forever at a specific URL. Include only the projects whose tests pass in the nightly KGS. Have a list elsewhere of the ones for which the tests fail. If the tests don't pass for some period of time, apparently the maintainers and users don't exist or don't care, and they get taken off the list to be tested. The Zope Framework team leader then decides some time to make a release, so people might shuffle around versions more than usual, but it's just another KGS. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote: Hey Gary, [panarchist approach where we have people starting groups that could compete for attention] [Had to look up panarchist, but yes, essentially.] I agree that it should be relatively easy to start Zope projects under the Zope umbrella. I agree that such projects could compete for attention and may the best one win. I think this is what's more or less already happening anyway, and I think it's great and it makes me appreciative of open source and Zope's component oriented culture that makes it possible. We can't just fork everything and branch off into our direction everywhere however; these projects will share a common codebase. I am very much in favor of someone having this perspective, and acting on it. ;-) This common codebase needs to be managed and have a direction, taking as inputs the needs of the projects using them. We don't have an umbrella project (e.g., grok, repoze) with this goal. I think your statements and mine mesh well enough. If you don't agree, that's fine. Practically, it means I support what you are trying to do (and in fact I would tend towards your camp in my proposed panarchy), if from a slightly different perspective. Gary Poster wrote: Moreover, if you are willing to step up and declare that you are starting something called the Zope Framework that manages a known good set of code, and you hope other projects and people join in and help, that makes sense to me. The open source mantra: those who take responsibility get responsibility Yup. I agree very much with that. It might be we are able to establish a framework team without elections by just picking out the bunch of people who are interested in this. Of course if we have a significant fraction of our community who disagrees with the authority to make decisions for larger changes in these components, we still have a problem. Two diverging branches of the same package doesn't seem to be a maintainable situation; at some point someone is going to make a release with a single version number. That's why I don't think I or anyone else can just do it without reaching a bit of wider consensus first. I think we have a transition problem to get from where we are now, where everybody and nobody is recognized, to a generally recognized group with some authority to make decisions where needed and provide guidance that should be taken into account. Sure. I'm glad you sent your proposal email first. Now that you have, I hope you pursue your vision without needing 100% buy-in from the community. I'm optimistic that you will. :-) Gary With what I've seen on the Grok list, you can do a great job as a project leader, generally being positive, open, and motivating. Thanks! I have my flaws, but I try to be aware of them. :) Yup, same here. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
On Mar 3, 2009, at 10:57 AM, Stephan Richter wrote: On Tuesday 03 March 2009, Gary Poster wrote: My mild counter proposal was this. - The ZF formally institutes an easy way for people to start Zope projects - Hopefully, Martijn F. starts something like the project he described - Hopefully, people follow it. In other words, I suppose, Just Do It. Actually Martijn tried to be better than that. :-) Instead of just forming a steering group (which I would interpret as a Zope project) and announcing it to the community, he asked for feedback first. :-) :-) Yes, that is better. I probably agree he should have just done it by gathering the various release managers. BTW, in one of my original responses, I proposed to Martijn that the steering group should be mostly the release managers plus one or two strong developers so that the group reaches an odd number. Now that he's proposed it, hopefully he does it, without 100% buy-in, as I just wrote to Martijn. Beyond that, I didn't say my other smaller thought, which was that I think the KGS should ideally be looser and more flexible than what Martijn described. If you have a project that wants in on the KGS, great, you can add it. That is the case right now and I think a steering group would be pretty open to additions. However, I think Martijn made a much more important point. What he wants, if I understood him correctly, is more of an organization around a hierarchy of KGSs. OK. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a common core and maybe a coreplus set. Then each sub-project maintains a KGS on top of that with their specific extensions. (1) This will make interoperability much easier, since I could potentially use grok X.Y in Zope 2.Z without worrying about version conflicts. (2) If the steering group contains all of the release managers, then releases can be synced effectively. Institute a nightly KGS for an upcoming release (and maybe the most recent release). We do have this system today. http://zope3.afpy.org/buildbot/waterfall Wow, great. Too bad about the failures. How are you announcing the failures ATM? It stays around forever at a specific URL. Include only the projects whose tests pass in the nightly KGS. Have a list elsewhere of the ones for which the tests fail. If the tests don't pass for some period of time, apparently the maintainers and users don't exist or don't care, and they get taken off the list to be tested. That statement is a massive over-simplification of what's going on. ;-) Heh, well, that's not exactly a surprise. :-) There are several problems: (1) Tests that pass in isolation might not pass in a complete run. This might be due to this or another packages incomplete teardown. (Several people spent weeks getting this right for the 3.4 KGS.) (2) A new release of one package might break 5 others. Who is responsible for updating the 5 breaking packages. The author that just released the new package or the ones from the 5 others? What if those other packages do not have clear, single maintainers (e.g. zope.*)? I am not making up these cases. They are real and they exist today. I know you are correct. I've experienced very similar things myself. The idea that one package has 1 or more concrete and devoted authors is simply not real in the Zope world of 200+ packages. Sure. There certainly are stakeholders who are willing to invest on this, particularly on core packages (where core differs for the stakeholders). The Zope Framework team leader then decides some time to make a release, so people might shuffle around versions more than usual, but it's just another KGS. Yep, this is basically what happens today. For example, at Keas we use different versions (even trunk) of at least 20 packages. The point is that people have a stable point to start with. I think that would not change. Great. (And thank you, this is much farther along than the last time I looked.) FWIW, the only polish I'd love to see is static pages for past dev releases (or did I miss them?) Thanks, Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the Zope Framework project
Thank you for the huge effort you expended on this, Martijn. You are right, with Jim taking a rest from his much-appreciated past years as leader, no one is in a position to guide the Zope name. We do have community leaders, such as yourself, but they are guiding other names at the moment. By focusing on reinvigorating the name Zope, I think we have an opportunity to move forward. This can be done loosely but with an opportunity for people such as yourself to take leadership. Zope Foundation members should be encouraged to propose Zope-named umbrella projects. Acceptance should be simple and loose--on the order of, you send an email to the ZF list to request use of a new Zope name, and the default answer to ZF members is yes, unless someone challenges it to a vote within four days, with simple majority rule in the ZF. That's a straw man, but hopefully conveys the idea. For instance and hypothetically, if you tomorrow wanted to start a new project called Zope Rocks that was to be some substrate of Grok, you should be encouraged. Moreover, if you are willing to step up and declare that you are starting something called the Zope Framework that manages a known good set of code, and you hope other projects and people join in and help, that makes sense to me. With what I've seen on the Grok list, you can do a great job as a project leader, generally being positive, open, and motivating. And importantly, it's just a use of the name: Zope. Other ZF developers might come along and say that Martijn character knows nothing--come join be on Zope Super Framework Libraries! I don't think they will, but they could, and would likely be given the same opportunity, given the simple and loose approach I described. That said, I suspect the vast majority of people will be appreciative of your efforts, and I suspect that you'll be able to marshal cooperation among many of the consumers of the current crop of Zope libraries. People that want a leadership position will seek you out and help. Hopefully you can get along. If not, watch out for the competing Zope Super Framework Libraries, coming soon. So that's what I would prefer, instead of the elected steering group. You want it, you do it. And Martijn, I hope you do. And if not, sure, I'll vote for the steering group, hopefully guided by the Plone experience Martin is recounting, just so we have *something*. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Review of zc.dict tlotze-blist branch
[Thomas asked me to review his zc.dict branch a while ago.] Hi Thomas. Thank you for this work. It looks great. I do have several comments below (from an abbreviated diff against the current trunk). Index: buildout.cfg === --- buildout.cfg (.../trunk) (revision 97211) +++ buildout.cfg (.../branches/tlotze-blist) (revision 97211) @@ -2,11 +2,10 @@ develop = . parts = test py -find-links = http://download.zope.org/distribution/ - [test] recipe = zc.recipe.testrunner -eggs = zc.dict +eggs = zc.dict [generations] +defaults = [-v, -c] I don't think the generations code should be required, and (since you used extras_require) neither do you. Therefore I'd prefer it if the main tests also didn't depend on that code. The way I've done this with other packages (e.g. http://svn.zope.org/zc.async/trunk/buildout.cfg?view=auto) is to have multiple test sections (with different names). The downside is that then, to run all possible tests, you have to run more than one command. The upside is that arguably the most important configuration--the base one--is truly tested. [py] recipe = zc.recipe.egg Index: CHANGES.txt === --- CHANGES.txt (.../trunk) (revision 97211) +++ CHANGES.txt (.../branches/tlotze-blist) (revision 97211) @@ -1,3 +1,8 @@ +1.3 (unreleased) + + +* changed the implementation of OrderedDict to store the order in buckets I suggest adding via zc.blist or something like that. ... Index: src/zc/dict/configure.zcml === --- src/zc/dict/configure.zcml (.../trunk) (revision 0) +++ src/zc/dict/configure.zcml (.../branches/tlotze-blist) (revision 97211) @@ -0,0 +1,5 @@ +configure xmlns=http://namespaces.zope.org/zope; + + include package=.generations / + +/configure configure.zcml has a semantic of always include. Because the generations code may not work for many people (as we've discussed before, and see comment in evolve test below), I'd prefer that the generations code have a semantic of optionally include. Therefore, I suggest you rename this to generations.zcml or something like that. ... Index: src/zc/dict/dict.py === --- src/zc/dict/dict.py (.../trunk) (revision 97211) +++ src/zc/dict/dict.py (.../branches/tlotze-blist) (revision 97211) ... def __setitem__(self, key, value): -delta = 1 -if key in self._data: -delta = 0 -self._data[key] = value -if delta: +if key not in self._data: self._order.append(key) -self._len.change(delta) +self._len.change(1) +self._data[key] = value Nice improvement in readability. def updateOrder(self, order): ... Also as mentioned before on the Zope list, until this API is deprecated in favor of one that encourages more granular changes, the change to blist only really helps the story for adding new items to an ordered dict. The Plone IExplicitOrdering interface looks reasonable, and could really take advantage of the blist characteristics. http://dev.plone.org/plone/browser/plone.folder/trunk/plone/folder/interfaces.py Index: src/zc/dict/generations/evolve1.txt === --- src/zc/dict/generations/evolve1.txt (.../trunk) (revision 0) +++ src/zc/dict/generations/evolve1.txt (.../branches/tlotze-blist) ... As we discussed earlier, findObjectsMatching will miss OrderedDicts that are used as internal data structures. I regard that as a primary use case for this package, so IMO that's important to note in the doc and in the Python file. Otherwise, looks great to me. Thank you! Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Single Sign On
On Feb 19, 2009, at 2:07 AM, Marius Gedminas wrote: I have the impression that you're talking past each other. There are two ways of using OpenID: * you can be an OpenID provider, i.e. accept logins with username password and respond to authentication requests from other websites confirming that the user does own this particular OpenID. * you can be an OpenID consumer, i.e. accept OpenID URLs from users and ask the corresponding OpenID provider to validate them. It's my impression that launchpad.net is an OpenID provider only, while Shane is trying to figure out how to use the OpenID consumer API in AuthKit. I could be mistaken about any of the particular points here. I'm glad that Shane replied that what Francis said helped him. FWIW, IRT Launchpad being an OpenID consumer, that's supposed to be a possibility very soon. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Single Sign On
On Feb 17, 2009, at 7:55 PM, Shane Hathaway wrote: Gary Poster wrote: Launchpad uses OpenID. We don't have that slated for abstraction and open-sourcing immediately. However, most of the Launchpad code (including this bit) is to be open-sourced by this summer, abstracted or not. Therefore, we should at least be able to give you some idea of what we have done before then. I've forwarded your email to the primary implementer/designer of our OpenID integration. Hopefully he can directly participate, or at least give me some answers to forward to you. Cool, thanks. Generally, we're using python-openid for the Zope code, and an Apache plugin as a front-end for hooking up other bits. In that case, what do you pass to Consumer.begin()? It expects a user URL and no password, yet launchpad.net accepts a user name and password. Shane Hi Shane. Francis Lacoste gave this answer: We use the OpenID 2.0 identifier select URL. This is a special OpenID url that basically means: identity using whatever ID you have on that server. The OpenID response will contain the actual OpenID identifier of the user at the end of the request. So sites that we integrate in our SSO simply sends you to Launchpad for authentication and then uses the returned identifier to link with their local account representation. We also use sreg (Simple Registration) to transfer information about the account to the integrated sites, so that they can update their local account representation with the central data. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.testing tests failing on trunk (using Python 2.4.6 and 2.5.4)
zope.testing trunk has five tests failing in Python 2.4.6 and four failing in Python 2.5.4 (on self-compiled versions on Mac OS X). Anyone know what the story is here? Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing tests failing on trunk (using Python 2.4.6 and 2.5.4)
On Feb 16, 2009, at 3:11 PM, Marius Gedminas wrote: On Mon, Feb 16, 2009 at 10:17:06AM -0500, Gary Poster wrote: zope.testing trunk has five tests failing in Python 2.4.6 and four failing in Python 2.5.4 (on self-compiled versions on Mac OS X). Anyone know what the story is here? No clue, especially since you haven't shown us what the failures are (Hint, hint.) :-) They were rather long. I tracked the majority of them down to Theuni, who graciously and quickly fixed them up. (r96602) He said there were some other failures when he started, in Py 2.4 and Py 2.5. I verified this. I corrected the errors in Py 2.5 and did a bit of other cleanup (r96603). One error remains in Py 2.4. I'll include the traceback below. Some paths are not included in Py2.4 for some reason. The cause was not immediately obvious, and I have day-off-and-I-have-a-cold laziness, so I didn't look further. As an aside, in Py 2.6, you get at least two deprecation warnings, and the tests appear to hang. Again, lazy. Didn't bother. Gary File /Users/gary/dev/zope.testing/src/zope/testing/testrunner/ testrunner-coverage.txt, line 18, in testrunner-coverage.txt Failed example: testrunner.run(defaults) Expected: Running samplelayers.Layer1 tests: Set up samplelayers.Layer1 in N.NNN seconds. Ran 9 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer11 tests: Set up samplelayers.Layer11 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer111 tests: Set up samplelayers.Layerx in N.NNN seconds. Set up samplelayers.Layer111 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer112 tests: Tear down samplelayers.Layer111 in N.NNN seconds. Set up samplelayers.Layer112 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer12 tests: Tear down samplelayers.Layer112 in N.NNN seconds. Tear down samplelayers.Layerx in N.NNN seconds. Tear down samplelayers.Layer11 in N.NNN seconds. Set up samplelayers.Layer12 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer121 tests: Set up samplelayers.Layer121 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running samplelayers.Layer122 tests: Tear down samplelayers.Layer121 in N.NNN seconds. Set up samplelayers.Layer122 in N.NNN seconds. Ran 34 tests with 0 failures and 0 errors in N.NNN seconds. Running zope.testing.testrunner.layer.UnitTests tests: Tear down samplelayers.Layer122 in N.NNN seconds. Tear down samplelayers.Layer12 in N.NNN seconds. Tear down samplelayers.Layer1 in N.NNN seconds. Set up zope.testing.testrunner.layer.UnitTests in N.NNN seconds. Ran 192 tests with 0 failures and 0 errors in N.NNN seconds. Tearing down left over layers: Tear down zope.testing.testrunner.layer.UnitTests in N.NNN seconds. lines cov% module (path) testrunner-ex/sample1/__init__.py) testrunner-ex/sample1/sample11/__init__.py) testrunner-ex/sample1/sample11/sampletests.py) testrunner-ex/sample1/sample13/__init__.py) testrunner-ex/sample1/sample13/sampletests.py) testrunner-ex/sample1/sampletests/__init__.py) testrunner-ex/sample1/sampletests/test1.py) testrunner-ex/sample1/sampletests/test11.py) testrunner-ex/sample1/sampletests/test111.py) testrunner-ex/sample1/sampletests/test112.py) testrunner-ex/sample1/sampletests/test12.py) testrunner-ex/sample1/sampletests/test121.py) testrunner-ex/sample1/sampletests/test122.py) testrunner-ex/sample1/sampletests/test_one.py) testrunner-ex/sample1/sampletestsf.py) testrunner-ex/sample2/__init__.py) testrunner-ex/sample2/sample21/__init__.py) testrunner-ex/sample2/sample21/sampletests.py) testrunner-ex/sample2/sampletests/__init__.py) testrunner-ex/sample2/sampletests/test_1.py) testrunner-ex/sample2/sampletests/testone.py) testrunner-ex/sample3/__init__.py) testrunner-ex/sample3/sampletests.py) testrunner-ex/samplelayers.py) testrunner-ex/sampletests/__init__.py) testrunner-ex/sampletests/test1.py) testrunner-ex/sampletests/test11.py) testrunner-ex/sampletests/test111.py) testrunner-ex/sampletests/test112.py) testrunner-ex/sampletests/test12.py) testrunner-ex/sampletests/test121.py) testrunner-ex/sampletests/test122.py) testrunner-ex/sampletests/test_one.py) testrunner-ex/sampletestsf.py) Total: 405 tests, 0 failures, 0 errors in N.NNN seconds. False Got: Running samplelayers.Layer1 tests: Set up samplelayers.Layer1 in N.NNN
Re: [Zope-dev] opensp...@pycon 2009 about Zope/Repoze/Grok/Deliverence etc.
On Feb 9, 2009, at 12:03 PM, Lennart Regebro wrote: Lots of things have happened in the Zope universe the last couple of years, and are still happening, some of which are turning Zope inside out, from a monolithic ghetto to a componentized agile speed monster. People outside the Zope world doesn't know about it, and although the Zope community mostly seems to be on the same page, I think it would be nice if we get as many as possible together to discuss the status and where things are going. And, if we don't have anything to discuss, we can drop off to some bar and toast at how great Zope is. :-) So, I propose to have an Open Space session at PyCon, Chicago, March 27-29 . As this is a part of the unconference bit of PyCon, you don't have to sign up, but you can say if you are coming here anyway, just so we get a feeling for the interest. And although we can't decide when to do this yet, if you are only able to go to PyCon certain days, say so here, so we'll know when we can get the most participants. I'm supposed to be at PyCon, but I haven't seen the confirmation yet. If I'm there, sounds good. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge zc.copy with zope.copypastemove and zope.location.
As the author, +1 and thank you! Gary On Feb 8, 2009, at 11:18 AM, Dan Korostelev wrote: Okay. I prepared the zope.copy package in the SVN for you to check out what I mean. :) 2009/2/8 Dan Korostelev nad...@gmail.com: After looking at the whole copy thing for some more time, I thought that it even makes sense to extract the object cloning functionality to some zope.copy (or even zope.persistentcopy) package that will contain clone and copy functions as well as ICopyHook mechanism, but won't contain IObjectCopier implementation, because the clone and copy functions from zc.copy are useful without any container context. Then zope.copypastemove and zope.location could just depend on the zope.copy, so we won't introduce many dependencies for zope.location and make people able to easily copy persistent objects w/o installing on zope.copypastemove or even zope.location. 2009/2/8 Dan Korostelev nad...@gmail.com: The README.txt of zc.copy says that the components, provided by this package is apropriate for inclusion in Zope itself. The package provides a more pluggable mechanism for copying generic persistent objects (not only ILocation's) as well as a way to register post-copy hooks to be executed, which is very useful, for example when dealing with persistent objects that have non-ZODB bits (like filesystem based files related and so on). However, the package is really small and mostly contains modified copies of zope.copypastemove's ObjectCopier and zope.location's locationCopy. So, I propose to merge the zc.copy package's changes with original zope.copypastemove/zope.location and deprecate it. If noone objects, I'll do that myself. -- WBR, Dan Korostelev -- WBR, Dan Korostelev -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Merge zc.copy with zope.copypastemove and zope.location.
On Feb 8, 2009, at 5:18 PM, Dan Korostelev wrote: 2009/2/9 Gary Poster gary.pos...@gmail.com: As the author, +1 and thank you! Glad to hear. I'll release the result of the merge soon. BTW, I'd also like to make a final release of zc.copy, replacing its code with dependencies/imports from newer zope.copy and zope.copypastemove. You mean 1.1. OK. If I were doing it, I would make 1.1b - 1.1, and then make a 1.2 that was as you described. If you don't agree or feel like it that's fine. Can you please add me to package owners on PyPI (my name there is nadako). Done. Also, should I use deprecated deferred imports or plain imports for that? I'm generally not a fan of the deprecated imports. I'd say just put it in the docs. Again, if you disagree, I don't feel too strongly about it. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Request input on bug about HTTP response.setStatus
Hi all. There's some disagreement about how to resolve the bug below, even though there's agreement that we want it resolved. Your input would be appreciated so we can find a consensus and move forward with a solution. https://bugs.edge.launchpad.net/zope3/+bug/322486 Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Some tools from the Launchpad project
Hi all. As announced elsewhere (and described in https://dev.launchpad.net/OpenSourcing) , Canonical's Launchpad project is working towards open-sourcing the majority of the code base by this summer. Prior and subsequent to the grand open-sourcing date, the Launchpad developers are encouraged to abstract stand-alone code for distributions. Since Launchpad uses several Zope libraries, some of the stand-alone packages may be of special interest to the Zope community. Unsurprisingly (at least if you know Launchpad), the packages use bzr for revision control, and Launchpad for codehosting, bug tracking, and so on. Currently we are standardizing on zc.buildout-based releases for these packages. We have two at the moment: http://pypi.python.org/pypi/lazr.delegates Provides an interesting Python delegation pattern. Uses zope.interface. http://pypi.python.org/pypi/lazr.config Helps build a configuration system (of whatever, but used here for process configuration). I'm not the author, just a messenger and liaison (and the guy who made the distros, in this case). (I did add some cookie conveniences to testbrowser recenty though--check out zope.testbrowser 1.6a1 if you want a look. :-) I, or other folks, will hopefully get a chance to send out other announcements of this sort in the future! Gary ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
