Re: [Zope-dev] zc.recipe.testrunner 1.4.0 no longer supports environment option?

2010-12-13 Thread Gary Poster

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)?

2010-08-23 Thread Gary Poster

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)?

2010-08-23 Thread Gary Poster

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)?

2010-08-23 Thread Gary Poster

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)?

2010-08-23 Thread Gary Poster

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)?

2010-08-23 Thread Gary Poster

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

2010-07-08 Thread Gary Poster

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.

2010-04-16 Thread Gary Poster

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

2010-04-15 Thread Gary Poster

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

2010-04-15 Thread Gary Poster

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)

2010-03-31 Thread Gary Poster

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

2010-01-26 Thread Gary Poster

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 ?

2010-01-22 Thread Gary Poster

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

2009-12-17 Thread Gary Poster
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...

2009-12-03 Thread Gary Poster

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...

2009-12-03 Thread Gary Poster

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...

2009-12-03 Thread Gary Poster

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

2009-12-03 Thread Gary Poster

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

2009-12-02 Thread Gary Poster

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

2009-12-02 Thread Gary Poster

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...

2009-12-02 Thread Gary Poster
...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

2009-12-02 Thread Gary Poster
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

2009-12-02 Thread Gary Poster

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

2009-12-01 Thread Gary Poster

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

2009-12-01 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-30 Thread Gary Poster

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

2009-11-25 Thread Gary Poster

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

2009-11-25 Thread Gary Poster

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

2009-11-25 Thread Gary Poster

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

2009-11-25 Thread Gary Poster

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)

2009-11-25 Thread Gary Poster

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] zc.relationship - can't pickle module objects

2009-11-09 Thread Gary Poster
Hi Patrick.  I do not have privileges for this egg, and am not  
responsible for it.  I'm hopeful someone can help you with it, though.

Gary


On Nov 9, 2009, at 5:55 AM, Patrick Gerken wrote:

 Hi,

 while this can't pickle issue is fixed in zc.relationship, the
 latest packaged egg
 of plone.relations still depends on zc.relationship1.1. Thus this
 issue persists if one uses the latest plone.relations egg.
 This has been fixed on in svn, could somebody with permissions  
 create a new egg?

 Best regards,

 Patrick



 On Tue, Mar 17, 2009 at 16:00, Gary Poster gary.pos...@gmail.com  
 wrote:

 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 )


___
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.

2009-11-03 Thread Gary Poster

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.

2009-11-03 Thread Gary Poster
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.

2009-11-03 Thread Gary Poster

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)

2009-10-06 Thread Gary Poster

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

2009-09-21 Thread Gary Poster
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

2009-09-18 Thread Gary Poster

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

2009-09-15 Thread Gary Poster

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

2009-09-15 Thread Gary Poster

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

2009-09-15 Thread Gary Poster

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] Subversion externals versus mirroring

2009-09-14 Thread Gary Poster

On Sep 11, 2009, at 9:34 AM, Chris Withers wrote:

 Martijn Faassen wrote:
 Christian Theune wrote:
 [snip]
 Same here. We also ended up in many deadlock situations having to
 sacrifice chickens for SVN to resume operations. That's why we  
 started
 investigating alternatives which are better at branching and  
 merging.

 Please keep up posted. We have a standing offer from Canonical to  
 host
 our stuff in bzr. The move of the Python core developers to  
 mercurial is
 also interesting.

 I've been impressed with TortoiseHg so far (after a few initial  
 hiccups)
 and it looks like they're aiming to be cross platform with it, which  
 is
 a pretty big draw, although the MacOS port isn't ready yet...

 How has TortoiseBzr progressed?

My understanding is that TortoiseBzr has largely withered on the vine  
in favor of a new effort: BzrExplorer, based on Qt, and running on  
Linux/Windows/Mac.

http://bazaar-vcs.org/BzrExplorer

That page has links to lots of information.  The very little  
information I have is based on those pages, so, for now, please look  
there for now rather than asking me anything.

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.

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

2009-09-14 Thread Gary Poster

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

2009-09-11 Thread Gary Poster

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

2009-09-11 Thread Gary Poster

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?

2009-09-11 Thread Gary Poster
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?

2009-09-11 Thread Gary Poster

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

2009-09-03 Thread Gary Poster
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

2009-08-27 Thread Gary Poster
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

2009-08-24 Thread Gary Poster
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

2009-08-24 Thread Gary Poster

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

2009-08-24 Thread Gary Poster

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?

2009-08-20 Thread Gary Poster

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?

2009-08-17 Thread Gary Poster
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?

2009-06-24 Thread Gary Poster

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

2009-06-22 Thread Gary Poster

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

2009-04-28 Thread Gary Poster
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

2009-04-24 Thread Gary Poster
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.

2009-04-15 Thread Gary Poster

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

2009-04-06 Thread Gary Poster

On Apr 6, 2009, at 6:51 AM, Chris Withers wrote:

 Martijn Pieters wrote:
 On Mon, Apr 6, 2009 at 11:53, Wichert Akkerman wich...@wiggy.net  
 wrote:
 Note that we are now up to svn 1.6.
 Which still does not fix this, and is preventing people from  
 upgrading
 to the 1.5 client, and thus from using checkouts using relative  
 paths.

 Bugger, that is indeed correct. I may not have any problems (and a
 workaround for svn bug 3119) but that doesn't mean we can ask other
 people that need access to more tightly ACL-ed repositories to put up
 with subversion 1.5 and 1.6.

 To be honest, the state of svn 1.5 is what's getting me to think about
 looking at mercurial.

 (bzr didn't take my fancy, and hg is gonna be used by the python-core
 folks, so I might as well learn that...)

 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.

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

2009-04-06 Thread Gary Poster


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

2009-04-03 Thread Gary Poster

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

2009-04-03 Thread Gary Poster

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

2009-04-03 Thread Gary Poster

On Apr 3, 2009, at 2:14 PM, Chris Rossi wrote:



 On Fri, Apr 3, 2009 at 1:55 PM, Gary Poster gary.pos...@gmail.com  
 wrote:

 How would that be a win for you (or anybody else) over just putting  
 the constant in the interfaces module?

 Standard practice seems to favor putting several interfaces in a  
 single interfaces module, so just putting the constants in the  
 module doesn't make it explicit that these constants go with a  
 particular interface.  Putting them on the interface itself makes  
 the relationship plain.

True.  FWIW, I usually do that in the text of the interface if I need  
to, but I absolutely see where you are coming from.

 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?


 Thanks for bringing that up.  I hadn't considered that.  In  
 languages with built-in interface support, classes generally  
 inherent constants from the interface, so automatically copying the  
 values over would seem to make sense.  Although it's also considered  
 best practice in those languages to refer to the constants by their  
 interface anyway, so one could argue that such a step could be  
 omitted.  Zope's implementation of interfaces is unique among  
 implementations I know about, in allowing programmers to mark live  
 objects with an interface, which would introduce an interesting edge  
 case with regards to copying constants over.  I'd say if the  
 implementation gets too polluted with edge cases, it's probably not  
 worth it.

Agree.

 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.

 Right, but since we have descriptors, why not use them?  Maybe I  
 should have used the Colbertian immutablish.

:-) Yeah, ok.

 I don't have my heart set on this.  I found a use case today and was  
 just thinking about ways to satisfy it.

If there's a reasonable story for the connection between interfaces  
and the objects providing them (that is, what we talked about above),  
then I wouldn't object.  I don't know what that reasonable story might  
be, though.

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

2009-04-03 Thread Gary Poster

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

2009-04-02 Thread Gary Poster

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

2009-03-25 Thread Gary Poster

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?

2009-03-25 Thread Gary Poster

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

2009-03-25 Thread Gary Poster

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

2009-03-17 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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

2009-03-16 Thread Gary Poster

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.

2009-03-09 Thread Gary Poster

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

2009-03-06 Thread Gary Poster

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

2009-03-06 Thread Gary Poster

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

2009-03-05 Thread Gary Poster

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)

2009-03-05 Thread Gary Poster

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

2009-03-05 Thread Gary Poster

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

2009-03-04 Thread Gary Poster

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

2009-03-03 Thread Gary Poster

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

2009-03-03 Thread Gary Poster

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

2009-03-03 Thread Gary Poster

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

2009-03-02 Thread Gary Poster
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

2009-02-24 Thread Gary Poster
[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

2009-02-19 Thread Gary Poster

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

2009-02-18 Thread Gary Poster

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 )


Re: [Zope-dev] Single Sign On

2009-02-17 Thread Gary Poster
Hi Shane.

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.

Generally, we're using python-openid for the Zope code, and an Apache  
plugin as a front-end for hooking up other bits.

Gary

On Feb 17, 2009, at 7:06 PM, Shane Hathaway wrote:

 I'm working with a customer on a single sign on (SSO) system for Zope.
 We haven't yet chosen which SSO system we want to use.  I would like  
 to
 hear from anyone who has set up SSO with Zope.

 We have some definite requirements:

 * We can't accept arbitrary identities like OpenID normally does.  We
 need to set up our own identity provider (IDP) and force our servers  
 to
 accept only identities provided by our own IDP.

 * The SSO process should be very similar to an ordinary cookie-based
 login process.  I don't want the user to have to enter their  
 username on
 one form and their password on another, but that's the standard OpenID
 process.

 * This will be implemented in Zope 3.

 We are considering OpenID, Shibboleth, CAS, and any other mature  
 system
 that others might suggest.  Shibboleth seems like the most obvious  
 fit,
 but it's nowhere near as popular as OpenID.  I haven't yet looked at  
 CAS
 in detail.

 Alternatively, I have wondered if we actually need full-blown SSO;
 perhaps a carefully constructed domain-wide cookie would do the trick.
 Any experiences with that?

 Thanks to anyone who participates.

 Shane
 ___
 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] zope.testing tests failing on trunk (using Python 2.4.6 and 2.5.4)

2009-02-16 Thread Gary Poster
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)

2009-02-16 Thread Gary Poster

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

  1   2   >