[Zope-dev] Changelog formatting [was: SVN: cmf.pt/trunk/ Preparing release.]

[Philipp von Weitershausen]

Malthe Borch wrote:
> Log message for revision 94141:
>   Preparing release.
> 
> Changed:
>   U   cmf.pt/trunk/CHANGES.txt
>   U   cmf.pt/trunk/setup.py
> 
> -=-
> Modified: cmf.pt/trunk/CHANGES.txt
> ===
> --- cmf.pt/trunk/CHANGES.txt  2008-12-17 11:44:23 UTC (rev 94140)
> +++ cmf.pt/trunk/CHANGES.txt  2008-12-17 12:52:37 UTC (rev 94141)
> @@ -1,7 +1,7 @@
>  Changelog
>  =
>  
> -In next release
> +cmf.pt 0.2 (released 12/17/2008)


I've noticed you're using the U.S. date format here which we discourage 
due to its ambiguity (in this case it happens not to be ambiguous, but 
that's just coincidence). The preferred format is the ISO 8601 dash 
notation (-MM-DD).

This and other things, such as the proper formatting of changelogs, are 
documented in a guide called "Maintaining Software in the Zope Software 
Repository" [1] of which "Releasing Software" [2] is a chapter. I admit 
they're not in the most public place, I'm just the guy who wrote them 
(by codifying best practices). Anybody who'd like to put them somewhere 
more visible is most welcome to (e.g. the Grok folks have put the 
Releasing Software document on their website [3]).


Happy holidays everyone,
Philipp


[1] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt
[2] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt
[3] http://grok.zope.org/documentation/how-to/releasing-software
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: zope.sendmail/trunk/ Copied over the UtilityTerm and UtilityVocabulary implementation from zope.app.component to avoid a dependency.

[Philipp von Weitershausen]

Hanno Schlichting wrote:
> Benji York wrote:
>> On Fri, Nov 14, 2008 at 7:23 PM, Hanno Schlichting <[EMAIL PROTECTED]> wrote:
>>> Log message for revision 92953:
>>>  Copied over the UtilityTerm and UtilityVocabulary implementation from 
>>> zope.app.component to avoid a dependency.
>> Instead of duplicating the code there should be a zope.utilityvocabulary
>> package that both zope.sendmail and zope.app.component can use.
> 
> I agree in principal. In this case the code is extremely tiny, though.
> 
> I'm not sure if packages which consist of only two simple classes are
> really that much of a good idea. There is an overhead in tracking
> dependencies and maintaining packages in itself. When the benefit of
> being able to reuse the same code outweighs this overhead is not clear
> to me.

If it's tiny, then the overhead is there only once, when the package is 
created and released, right? After than you can just leave it alone and 
never ever have to think about it again.

___
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 2.12 features

[Philipp von Weitershausen]

Jens Vagelpohl wrote:
> On Nov 4, 2008, at 13:59 , Hanno Schlichting wrote:
> 
>> If I'm not mistaken there was something about every release being
>> supported two years after its initial release in those discussions.
>>
>> But time went on, we haven't sticked to a time-based release schedule
>> and those policies haven't been written down or been followed.
> 
> 2 years sounds fine to me.
> 
> By that reasoning, we can stop supporting 2.8 (2.8.0 was released June  
> 11, 2005) and 2.9 (2.9.0 was released January 9, 2006). However, if we  
> were strict it would also mean EOL for 2.10 (2.10.0 was released  
> October 4, 2006). But we can be lenient...

+1 to retiring 2.8, 2.9. Of course, if people still want to maintain it, 
they should be welcome to. I just don't think we should have to merge 
bugfixes to those branches anymore. Maintaining 2.10, 2.11, trunk seems 
perfectly acceptable and it's plenty to deal with.

___
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 1.0.2 typo bug

[Philipp von Weitershausen]

Rudá Porto Filgueiras wrote:
> I found a typo bug in zc.relationship 1.0.2 (pypi and svn tag 1.02).
> It's fixed in trunk but not backported and plone.app.relations-1.0b2
> unittest found this bug.

Thanks for the bug report and the patch. Could you please report it at 
https://bugs.launchpad.net/zope3? Thank you!
___
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] Proposal: Backporting some Python 2.5/2.6 fixes

[Philipp von Weitershausen]

Andreas Jung wrote:
> On 27.10.2008 18:55 Uhr, Sidnei da Silva wrote:
>> On Mon, Oct 27, 2008 at 3:42 PM, Andreas Jung<[EMAIL PROTECTED]>  wrote:
>>> Why do we need these backports on the current maintenance branches?
>>
>> They are small cleanups that could potentially allow someone to run
>> Python 2.5 or 2.6 if they really really really wanted to, but note
>> should be made that it would be completely and utterly unsupported.
> 
> Please create branches first and then lets review the changes. What is 
> the state of the compatability of Z3 modules with Python 2.5/2.6 as used 
> in Zope 2.10/2.11?

Zope 2.10 contains Zope 3.3 which most likely doesn't work on Python 
2.5. Nobody has bothered to take a look, really, since it's ages old.

Zope 2.11 contains the Zope 3.4 KGS, as far as I'm aware. If the 3.4 KGS 
refers to the latest bugfix releases of all packages, then it works on 
Python 2.5.

Superficially, many Zope 3 packages also work on Python 2.6 (e.g. Grok 
runs), but a closer look reveals various test failures.


IMHO we shouldn't worry about 2.10 and 2.11 and just care about 2.12 at 
this point. By now it should work with Python 2.5, right? Let's release 
it soonish. Not only will it bring Python 2.5 compatibility but it also 
gets rid of Acquisition-wrapped views and introduces (optional) 
__parent__ pointers. Three years after having started the 
implementation, I think it's time to get it out there :)
___
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] Need help - wrong hierarchy on svn.zope.org

[Philipp von Weitershausen]

kevin gill wrote:
> I need a little help. I checked two packages into svn.zope.org, but I have
> set up the hierarchy incorrectly.
> 
> The packages are z3c.rotterdam and z3c.boston. The egg is in the base
> folder, rather than in 'trunk'.
> 
> I would appreciate it if someone with administration access to the
> repository could fix the paths.

You can easily do that yourself:

   svn mv $z/z3c.rotterdam $z/z3c.rotterdam-trunk
   svn mkdir $z/z3c.rotterdam
   svn mv $z/z3c.rotterdam-trunk $z/z3c.rotterdam/trunk

and the same thing with z3c.boston. Note that the $z environment 
variable is defines as follows:

   export z=svn+ssh://svn.zope.org/repos/main

or if your remote user name differs from the local one:

   export z=svn+ssh://[EMAIL PROTECTED]/repos/main
___
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.app.container won't compile

[Philipp von Weitershausen]

Andreas Jung wrote:
> On 19.10.2008 14:14 Uhr, Andreas Jung wrote:
>> On 19.10.2008 14:04 Uhr, Roger Ineichen wrote:
>>> Hi Andreas
>>>
 Betreff: [Zope-dev] zope.app.container won't compile

 A buildout fails reproducable both on Mac and Linux...how is
 the guilty?
>>>
>>> Same on windows with Python 2.4.
>>>
>>> I think this is a Python 2.4 to Python 2.5 migration issue
>>> and not platform dependent.
>>>
>>> Are you using Python 2.4?
>>
>> Sure. If someone made Python 2.4 incompatible changes then they have to
>> reverted :->
> 
> [EMAIL PROTECTED] neither compiles directly using "python 
> setup.py build" - neither with Python 2.4 nor 2.5 nor 2.6. Also running
> the bootstrap.py; bin/buildout dance does not work in any way...wtf???

Works here with Python 2.4, 2.5 and 2.6:

[EMAIL PROTECTED]:~$ cd temp
[EMAIL PROTECTED]:~/temp$ svn co $z/zope.app.container/trunk zope.app.container
...
Checked out revision 92387.
[EMAIL PROTECTED]:~/temp$ cd zope.app.container



[EMAIL PROTECTED]:~/temp/zope.app.container$ python2.4 setup.py build
running build
running build_py
...
running egg_info
...
running build_ext
building 'zope.app.container._zope_app_container_contained' extension
creating build/temp.macosx-10.3-i386-2.4
creating build/temp.macosx-10.3-i386-2.4/src
creating build/temp.macosx-10.3-i386-2.4/src/zope
creating build/temp.macosx-10.3-i386-2.4/src/zope/app
creating build/temp.macosx-10.3-i386-2.4/src/zope/app/container
gcc -I/opt/local/include -L/opt/local/lib -fno-strict-aliasing 
-Wno-long-double -no-cpp-precomp -mno-fused-madd -DNDEBUG -g -O3 -Wall 
-Wstrict-prototypes -Iinclude -I/Users/philipp/include/python2.4 -c 
src/zope/app/container/_zope_app_container_contained.c -o 
build/temp.macosx-10.3-i386-2.4/src/zope/app/container/_zope_app_container_contained.o
gcc -I/opt/local/include -L/opt/local/lib -bundle -undefined 
dynamic_lookup 
build/temp.macosx-10.3-i386-2.4/src/zope/app/container/_zope_app_container_contained.o
 
-o 
build/lib.macosx-10.3-i386-2.4/zope/app/container/_zope_app_container_contained.so



[EMAIL PROTECTED]:~/temp/zope.app.container$ python2.5 setup.py build
running build
running build_py
...
running egg_info
...
running build_ext
building 'zope.app.container._zope_app_container_contained' extension
creating build/temp.macosx-10.3-i386-2.5
creating build/temp.macosx-10.3-i386-2.5/src
creating build/temp.macosx-10.3-i386-2.5/src/zope
creating build/temp.macosx-10.3-i386-2.5/src/zope/app
creating build/temp.macosx-10.3-i386-2.5/src/zope/app/container
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp 
-mno-fused-madd -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-Iinclude -I/opt/include/python2.5 -c 
src/zope/app/container/_zope_app_container_contained.c -o 
build/temp.macosx-10.3-i386-2.5/src/zope/app/container/_zope_app_container_contained.o
gcc -bundle -undefined dynamic_lookup 
build/temp.macosx-10.3-i386-2.5/src/zope/app/container/_zope_app_container_contained.o
 
-o 
build/lib.macosx-10.3-i386-2.5/zope/app/container/_zope_app_container_contained.so



[EMAIL PROTECTED]:~/temp/zope.app.container$ python2.6 setup.py build
running build
running build_py
...
running egg_info
...
running build_ext
building 'zope.app.container._zope_app_container_contained' extension
creating build/temp.macosx-10.3-i386-2.6
creating build/temp.macosx-10.3-i386-2.6/src
creating build/temp.macosx-10.3-i386-2.6/src/zope
creating build/temp.macosx-10.3-i386-2.6/src/zope/app
creating build/temp.macosx-10.3-i386-2.6/src/zope/app/container
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes -Iinclude -I/opt/include/python2.6 -c 
src/zope/app/container/_zope_app_container_contained.c -o 
build/temp.macosx-10.3-i386-2.6/src/zope/app/container/_zope_app_container_contained.o
gcc -bundle -undefined dynamic_lookup 
build/temp.macosx-10.3-i386-2.6/src/zope/app/container/_zope_app_container_contained.o
 
-o 
build/lib.macosx-10.3-i386-2.6/zope/app/container/_zope_app_container_contained.so



[EMAIL PROTECTED]:~/temp/zope.app.container$ python2.4 bootstrap.py
Creating directory '/Users/philipp/temp/zope.app.container/bin'.
Creating directory '/Users/philipp/temp/zope.app.container/parts'.
Creating directory '/Users/philipp/temp/zope.app.container/develop-eggs'.
Generated script '/Users/philipp/temp/zope.app.container/bin/buildout'.

[EMAIL PROTECTED]:~/temp/zope.app.container$ bin/buildout
Develop: '/Users/philipp/temp/zope.app.container/.'
Installing test.
Generated script '/Users/philipp/temp/zope.app.container/bin/test'.

[EMAIL PROTECTED]:~/temp/zope.app.container$ bin/test
Running zope.app.container.testing.AppContainerLayer tests:
   Set up zope.app.container.testing.AppContainerLayer in 10.527 seconds.
   Ran 15 tests with 0 failures and 0 errors in 1.326 seconds.
Running zope.testing.testrunner.layer.UnitTests tests:
   Tear down zope.app.container.testing.AppContainerLayer in 0.001 seconds.
   Set up zope.testing.testrunner.layer.UnitTests in 0.000

Re: [Zope-dev] zope.app.container won't compile

[Philipp von Weitershausen]

Andreas Jung wrote:
>> A trunk checkout compiles cleanly on Python 2.4:  Sidnei checked in a
>> fix for this problem on Thursday.
> 
> I assume this made it into zope.app.container 3.6.1 released on October 
> 15th:
> 
> http://pypi.python.org/pypi/zope.app.container
> 
> So why won't this version build with Python 2.4?

Sidnei fixed the 3.6.1 tag locally to build on Python 2.4. The fix 
hasn't made it into a release yet. So far I didn't want to create a 
release because I'm puzzled by the problem myself:

zope.app.container 3.5.6 builds on Python 2.4 perfectly without Sidnei's 
fix. However, zope.app.container 3.6.x will only build on Python 2.4 
*with* Sidnei's fix (which is available from trunk). Regarding their C 
code, the two branches seem to be identical as far as I can tell (for 
instance, compare 3.5.6 to 3.6.1). That's why I'm a bit puzzled. Perhaps 
somebody else can shed light on this.

Of course, if everybody's just annoyed and wants to move on, I'll be 
happy to create another 3.6.2 release with Sidnei's fix in it.

> In addition this release has a source dist and two eggs (for 2.4 and 
> 2.5). Wasn't there consensus to upload sdists only (except for Windows)?

Right. I uploaded an sdist and Sidnei uploaded two binary eggs for 
Windows. Where's the problem?
___
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] traversal: different with and without a request

[Philipp von Weitershausen]

El 17 Oct 2008, a las 15:02 , Jim Fulton escribió:
>> First of all, its name is quite misleading.  It should really be  
>> called
>> 'zope.resolvepath' because it resolves TALES-like object paths. In  
>> fact,
>> it's pretty much only used by the PageTemplate machinery to hook it  
>> up
>> to the TALES engine (with one exception, see below).
>
> Historical note. Until we decided to use the location framework and  
> eschew traversal proxies, is was much more widely used.
>
> It would be nice to deprecate zope.traversing and fold it into  
> zope.app.pagetemplate.

+1

>> The request shouldn't really be necessary for this kind of path  
>> resolution, I think.
>
> It's needed for looking up views and resources, both of which are  
> commonly looked up in ZPT.

Yeah, I forgot about that.

>> The conditional multi-adaption sounds like a DWIM feature that I  
>> would
>> consider one of our many mistakes that we made in the beginnings of  
>> our
>> using the Component Architecture.
>
> 
>
> I'll note that the fix, in the context of ZPT is to always to a  
> multi-adapter lookup using the request.

Right. I'm fine with it always being a multi-adapter look-up.

___
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] traversal: different with and without a request

[Philipp von Weitershausen]

El 17 Oct 2008, a las 10:37 , Christian Theune escribió:
>> There is a process that actually needs the request and this process  
>> is
>> what I call traversal: breaking down a URL and finding a publishable
>> object. zope.traversing has (almost) nothing to do with it, the real
>> kind of traversal happens in the publisher and facilitates
>> IPublishTraverse adapters (rather than ITraversable). The only case  
>> when
>> the two kinds of "traversal" are intermingled is when ++namespaces+ 
>> + are
>> involved. Then IPublishTraverse-style traversal uses ITraversable
>> adapters. This has long been considered a mistake but was never  
>> fixed.
>
> URL traversal makes use of zope.traversing though.

Yes, but only in the special case of ++namespace++ traversal. This is  
what I said in the above paragraph already. zope.publisher itself  
doesn't depend on zope.traversing and the default publication  
implementation in zope.app.publication uses zope.traversing only for + 
+namespace++ names (see usage of zope.traversing.namespace.nsParse in  
zope 
.app.publication.publicationtraverse.PublicationTraverse.traverseName).

___
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] traversal: different with and without a request

[Philipp von Weitershausen]

Dieter Maurer wrote:
> Christian Theune wrote at 2008-10-15 17:42 +0200:
>> we stumbled over an annoyance that took a while to debug:
>>
>> Writing an ITraversable, we used zope.traversing.api.traverse() in a
>> test to verify our code. We registered the ITraversable as an
>> (non-multi) adapter and ended up with a working test.
>>
>> In the actual system, we found that the traversable would not be used.
>> After investigation we found a conditional branch in the traverse()
>> function which would look for a multi-adapter if a request was around,
>> and a regular adapter if not.
>>
>> We didn't anticipate this difference and it cost us some time, so we
>> wonder whether this has to be the way it is, or whether this could be
>> changed to behave more obvious and consistent.
> 
> The request may have important information to control traversal, e.g.
> a layer. On the other hand, when no request is available (e.g. in a
> script), you cannot use one. Thus, the current behaviour may cover
> useful use cases.

True. The request (=layer) is indeed necessary to resolve paths in the 
++view++ aka @@ namespace.
___
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] traversal: different with and without a request

[Philipp von Weitershausen]

El 15 Oct 2008, a las 19:24 , Shane Hathaway escribió:
> Philipp von Weitershausen wrote:
>> First of all, its name is quite misleading. It should really be  
>> called
>> 'zope.resolvepath' because it resolves TALES-like object paths. In  
>> fact,
>> it's pretty much only used by the PageTemplate machinery to hook it  
>> up
>> to the TALES engine (with one exception, see below). The request
>> shouldn't really be necessary for this kind of path resolution, I  
>> think.
>>  The conditional multi-adaption sounds like a DWIM feature that I  
>> would
>> consider one of our many mistakes that we made in the beginnings of  
>> our
>> using the Component Architecture.
>>
>> There is a process that actually needs the request and this process  
>> is
>> what I call traversal: breaking down a URL and finding a publishable
>> object. zope.traversing has (almost) nothing to do with it, the real
>> kind of traversal happens in the publisher and facilitates
>> IPublishTraverse adapters (rather than ITraversable). The only case  
>> when
>> the two kinds of "traversal" are intermingled is when ++namespaces+ 
>> + are
>> involved. Then IPublishTraverse-style traversal uses ITraversable
>> adapters. This has long been considered a mistake but was never  
>> fixed.
>>
>> I'm not sure my explanation are helpful ;). Did I mention it was a  
>> mess?
>
> This is very useful information that would have saved me a lot of
> confusion years ago.  Is this written somewhere permanent, at least?

Not that I know of. The documentation of zope.traversing would  
probably be a good place to put it.

___
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.interface: verifyObject vs properties

[Philipp von Weitershausen]

Thomas Lotze wrote:
> Jim Fulton <[EMAIL PROTECTED]> wrote:
> 
>> I would change it to just use getattr rather than hasattr.
>>
>> try:
>> getattr(ob, name)
>> except AttributeError:
>> return False
>> ...
> 
> This doesn't handle the case that the attribute exists as a property
> but raises an AttributeError when trying to produce its value.

Yes, but this is still better than hasattr() which eats all exceptions. 
I think eating AttributeErrors is fine because to the user of 'ob', it 
would seem that ob.attr wouldn't exist anyway if it threw an 
AttributeError (even if that exception was about something else, it's 
still an AttributeError).

I suggest doing

   marker = object()
   return getattr(ob, name, marker) is marker

rather than

   return hasattr(ob, name)
___
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] traversal: different with and without a request

[Philipp von Weitershausen]

Christian Theune wrote:
> we stumbled over an annoyance that took a while to debug:
> 
> Writing an ITraversable, we used zope.traversing.api.traverse() in a
> test to verify our code. We registered the ITraversable as an
> (non-multi) adapter and ended up with a working test.
> 
> In the actual system, we found that the traversable would not be used.
> After investigation we found a conditional branch in the traverse()
> function which would look for a multi-adapter if a request was around,
> and a regular adapter if not.
> 
> We didn't anticipate this difference and it cost us some time, so we
> wonder whether this has to be the way it is, or whether this could be
> changed to behave more obvious and consistent.

zope.traversing is a mess.

First of all, its name is quite misleading. It should really be called 
'zope.resolvepath' because it resolves TALES-like object paths. In fact, 
it's pretty much only used by the PageTemplate machinery to hook it up 
to the TALES engine (with one exception, see below). The request 
shouldn't really be necessary for this kind of path resolution, I think. 
  The conditional multi-adaption sounds like a DWIM feature that I would 
consider one of our many mistakes that we made in the beginnings of our 
using the Component Architecture.

There is a process that actually needs the request and this process is 
what I call traversal: breaking down a URL and finding a publishable 
object. zope.traversing has (almost) nothing to do with it, the real 
kind of traversal happens in the publisher and facilitates 
IPublishTraverse adapters (rather than ITraversable). The only case when 
the two kinds of "traversal" are intermingled is when ++namespaces++ are 
involved. Then IPublishTraverse-style traversal uses ITraversable 
adapters. This has long been considered a mistake but was never fixed.

I'm not sure my explanation are helpful ;). Did I mention it was a mess?
___
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 2.12 - supported Python versions

[Philipp von Weitershausen]

Hanno Schlichting wrote:
> Stephan Richter wrote:
>> On Wednesday 15 October 2008, Sidnei da Silva wrote:
>>> I don't want to rain on your parade, but I already did a first pass at
>>> reviewing the changes in Python 2.5 and Python 2.6. There are no
>>> significant changes that I could spot so far. Apparently the major
>>> changes are:
>> I also did a review for Python 2.5 a while ago...
> 
> So does this mean RestrictedPython just had a bad emotional status in
> the community, but it is actually well proven and reviewed now?

It has been reviewed by Jim for Python 2.4. When he did this, he wrote 
notes.txt which gives you a quick overview over the internals. The 
GSoC-sponsored efforts to port Zope 3 and Zope 2 to Python 2.5 included 
a review of RestrictedPython as well. As far as I can tell, the only 
changes to RestrictedPython were made by Sidnei a couple of days ago 
when he fixed it up for the new keywords in Python 2.6 and added some 
tests for features new in Python 2.5 and 2.6.

> I always was under the impression that Jim feared the code and the
> required security audit was perceived as a major painful undertaking.

It's certainly something that should be undertaken carefully. New 
syntactical features (such as the =+ operator in the past, or the 'with' 
statement or inplace 'if' now) have to be analyzed with respect to their 
bytecode. Bytecode changes have to be tracked as well.


It looks like Sidnei is on top of that already, though, which is 
certainly great to hear! Go Sidnei! :)
___
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] Relative Imports: PEP-328

[Philipp von Weitershausen]

El 8 Oct 2008, a las 14:23 , Sidnei da Silva escribió:

> On Wed, Oct 8, 2008 at 8:53 AM, Philipp von Weitershausen
> <[EMAIL PROTECTED]> wrote:
>> Sidnei da Silva wrote:
>>>
>>> I'm trying to fix some import errors, which seem to be related to  
>>> PEP-328.
>>>
>>> I'm fixing those errors this way, though I don't know if that's the
>>> recommended way of fixing it. Thoughts?
>>>
>>> """
>>> try:
>>>   from DT_Util import parse_params, name_param
>>> except ImportError:
>>>   # See PEP-328
>>>   from .DT_Util import parse_params, name_param
>>> """
>>
>> This will generate a SyntaxError in Python 2.4. So unless we  
>> *require*
>> Python >= 2.5, this won't work.
>
> Yuck. I hadn't thought of that. Any other suggestions? Like, using
> zope.documenttemplate? :)

zope.documenttemplate is a crippled version of DocumentTemplate. It  
doesn't have all features (e.g. it lacks the C extension module) and  
hasn't been kept up-to-date with respect to bugfixes. So it seems like  
a good idea to put this clone out of its misery and retire it.

I ultimately suggest going to absolute imports everywhere (at least as  
long as we have to maintain Python 2.4 compatibility). I realize that  
DocumentTemplate/DocumentTemplate.py creates a problem. So here's what  
I suggest:

   1. Rename DocumentTemplate/DocumentTemplate.py to, say,
  DocumentTemplate/DocTemplate.py (feel free to come up with
  a better name)

   2. Introduce absolute imports to DocumentTemplate.DocTemplate
  everywhere

   3. Ensure backwards compatibility by adding the following lines
  to DocumentTemplate/__init__.py::

 import DocumentTemplate.DocTemplate
 import sys
 sys.modules['DocumentTemplate.DocumentTemplate'] =  
DocumentTemplate.DocTemplate

I *think* this should work.

___
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] Python 2.6: 'with' in Interfaces

[Philipp von Weitershausen]

Marius Gedminas wrote:
> On Wed, Oct 08, 2008 at 12:35:39AM -0300, Sidnei da Silva wrote:
>> Trying to run some tests with Python 2.6 I stumbled on a problem that
>> I need help with: an interface that has an attribute named 'with'.
>>
>> The interface in question is defined in zope.app.component.back35:
>>
>> class IAdapterRegistration(IComponentRegistration):
>> ...
>> with = schema.Tuple(
>> title = _("With interfaces"),
>> ...
>>
>> Any suggestions on how to fix this one?
> 
> The backwards-compatibility interfaces are supposed to expire after 3
> releases (or was it years?), maybe we can simply remove this one?

+1. The deprecation message says it's going away in Zope 3.5, so I 
suggest ripping all this stuff out on the trunk of zope.app.component 
and creating a new major release (which would then be Python 2.6 
compatible).

___
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] Relative Imports: PEP-328

[Philipp von Weitershausen]

Sidnei da Silva wrote:
> I'm trying to fix some import errors, which seem to be related to PEP-328.
> 
> I'm fixing those errors this way, though I don't know if that's the
> recommended way of fixing it. Thoughts?
> 
> """
> try:
> from DT_Util import parse_params, name_param
> except ImportError:
> # See PEP-328
> from .DT_Util import parse_params, name_param
> """

This will generate a SyntaxError in Python 2.4. So unless we *require* 
Python >= 2.5, this won't work.
___
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] RFC: adding support for testing from bare setuptools

[Philipp von Weitershausen]

Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Tres Seaver wrote:
>> Tres Seaver wrote:
>>
>> I have checked the proposed changes to 'zope.testing' in on a branch,
>> which I would like to merge to the trunk and release as 3.7:
>>
>> svn+ssh://svn.zope.org/repos/main/zope.testing/branches/tseaver-eggsupport
>>
>> Objections?
> 
> Hearing none, yesterday I merged the branch to the trunk and tagged a
> 3.7.0 release.  I would like to get the sdist for that uploaded to PyPI,
> but don't have access.  Can one of the maintainers there either grant me
> access or upload the sdist themselves?  That would be one of:
> 
>  srichter, mgedmin, ajung, philikon, J1m, fdrake

Seems like this was done already. You should be able to upload the tarball.
___
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] RFC: adding support for testing from bare setuptools

[Philipp von Weitershausen]

Marius Gedminas wrote:
> On Wed, Sep 17, 2008 at 12:52:49PM -0400, Tres Seaver wrote:
>> Proposal
>> 
>>
>> Instead, what I *am* proposing is adding metadata which allows consumers
>> of such packages to verify that the package is downloaded / installed
>> correctly.  In particular, I want for the following scenario to work
>> seamlessly::
>>
>>  $ /path/to/virtualenv --no-site-packges sandbox
>>  ...
>>  $ cd sandbox
>>  $ tar xzf zope.foo.bar-3.5.6.tar.gz
>>  $ cd zope.foo.bar-3.5.6   # [1]
>>
>>  $ ../bin/python setup.py test # [2]
>>  # Runs egg_info, installs regular and testing dependencies, and
>>  # runs all unit (non-layer) tests
> 
> I don't like the idea that running the tests installs additional
> packages into my environment without me explicitly asking for it.

You *are* asking for it by running python setup.py test. Also, python 
setup.py test doesn't actually install testing dependencies (or any 
dependencies for that matter) into site-packages. It just dumps them 
into the CWD.
___
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.component: calling an Interface and calling queryAdapter give differing results

[Philipp von Weitershausen]

El 9 Sep 2008, a las 20:37 , Dieter Maurer escribió:
> Chris Withers wrote at 2008-9-8 18:34 +0100:
>> ...
>>> There's the backward-compatibility issue, which is a showstopper.
>>> There's plenty of code that does this:
>>>
>>>adapter = package.interfaces.IFoo(object, None)
>>>
>>> Changing the signature as you describe would break all code that  
>>> does this.
>>
>> How about a new major revision of zope.interface then?
>
> I fear that would be a bit drastic -- for a mostly cosmetic change.

I agree.

> But interfaces might grow an additional method, e.g. "adapt",
> which could get the new signature.
>
> The syntax would be a bit more cumbersome -- but on the other
> hand, it would be more explicit :-)

I don't think it would be too cumbersome. While IMHO elegant, the  
current syntax of calling an interface to adapt isn't actually self- 
explanatory. I've frequently observed people tripping over this,  
specially when you have an IFoo interface and a Foo class -- which is  
quite common --, then IFoo(obj) and Foo(obj) differ only by one  
character. With your suggestion, it would be IFoo.adapt(obj) vs.  
Foo(obj), making the difference quite obvious.

So overall I'm +1

___
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] batching zope.sendmail

[Philipp von Weitershausen]

Daniel Widerin wrote:
> hi guys
> 
> i'm out of the plone world and since i'm developing for singing&dancing 
> i would really like to have batching included into zope.sendmail.
> 
> queuedDelivery does have self.interval which defines time between each 
> queue-run. most mailservers accept only 10 connections at the same time 
> and thats the point why we should think about batching.
> 
> i've played around with zope.sendmail 3.5 and implemented batching on my 
> testserver.

Great!

> anybody interested for commiting this into a new branch/trunk and have a look 
> at it?

The best way to get the code into svn.zope.org is if you become a Zope 
Contributor. This means signing the Contributor Agreement [1] and faxing 
it or emailing a scanned version to Zope Corporation.

Once you're a contributor, you're most welcome to check your fixes and 
features (including automated tests, which are a requirement for any 
change in code) into a branch of zope.sendmail. I'm hopeful somebody 
who's worked on zope.sendmail in the past will volunteer to review your 
changes.


[1] http://www.zope.org/DevHome/CVS/Contributor.pdf


___
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] SVN: z3c.pt/trunk/TODO.txt

[Philipp von Weitershausen]

Malthe Borch wrote:
> Chris McDonough wrote:
>> Log message for revision 90974:
>> Added: z3c.pt/trunk/TODO.txt
>> ===
>> --- z3c.pt/trunk/TODO.txt(rev 0)
>> +++ z3c.pt/trunk/TODO.txt2008-09-09 00:03:08 UTC (rev 90974)
>> @@ -0,0 +1,4 @@
>> +- Make e.g.  and  etc.
>> +  work
> 
> Are we sure we want this? It's (afaik) not correct XML;

It's not? How so?
___
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] Dependencies and future of zope 3

[Philipp von Weitershausen]

Benji York wrote:
> On Wed, Sep 3, 2008 at 11:41 AM, Stephan Richter
> <[EMAIL PROTECTED]> wrote:
> 
>> For several packages we took the following approach. Most packages that have
>> browser packages are in zope.app; for example, zope.app.folder (we did not
>> convert this package yet). We then took the API and moved it to zope.folder.
> 
> Maybe we should create a new namespace package for "browser" code.
> 
> How about "zope.browser"?

-0

My general sentiment is against creating more structure than we already 
have. Flat is better than nested. IMHO it's perfectly ok to have the 
Python APIs in zope.foo and browser code in zope.app.foo. I think sooner 
than later people won't want to the zope.app.* stuff anyway.

___
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.component: calling an Interface and calling queryAdapter give differing results

[Philipp von Weitershausen]

El 1 Sep 2008, a las 19:26 , Dieter Maurer escribió:
> Chris Withers wrote at 2008-9-1 16:23 +0100:
>> ...
>>>   auth = IAuthentication() # utility
>>>   auth = IAuthentication(default=None)
>>>   langs = IUserPreferredLanguages(request) # adapter
>>>   langs = IUserPreferredLanguages(request, default=None)
>>>   view = IBrowserPage((obj, request), name='index')# named
>>> multi-adapter
>>
>> Right, but how do you differentiate adapting a tuple to IBrowserPage
>> versus adapting obj and request together to IBrowserPage?
>
> One way would be to use "*objs" in the "Interface.__call__" signature.
> Then, multi-adaptation could be "I(obj1, obj2, ...)" and
> tuple adaptation "I((obj1, obj2, ...)).
> Of course, all other parameters would need to be keyword parameters
> (a good thing).
>
> Do you have a serious use case for tuple adaptation?

IIRC, the twisted guys do.

___
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.component: calling an Interface and calling queryAdapter give differing results

[Philipp von Weitershausen]

El 1 Sep 2008, a las 17:23 , Chris Withers escribió:
> Philipp von Weitershausen wrote:
>> I've personally thought for some time that it would be quite nice  
>> if  all you had to do was call an interface to look up a utility  
>> (which is  sort of a multi-adapter of order 0) or to do some kind  
>> of adaption, no  matter how many objects you wanted to adapt. E.g.:
>
> +sys.maxint. This is nice.
>
>>   auth = IAuthentication() # utility
>>   auth = IAuthentication(default=None)
>>   langs = IUserPreferredLanguages(request) # adapter
>>   langs = IUserPreferredLanguages(request, default=None)
>>   view = IBrowserPage((obj, request), name='index')# named   
>> multi-adapter
>
> Right, but how do you differentiate adapting a tuple to IBrowserPage  
> versus adapting obj and request together to IBrowserPage?

You don't, I guess. I'd say that multi-adaption is *defined* as the  
adaption of a tuple.

___
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.component: calling an Interface and calling queryAdapter give differing results

[Philipp von Weitershausen]

El 30 Aug 2008, a las 07:50 , Dieter Maurer escribió:
> Chris Withers wrote at 2008-8-29 10:25 +0100:
>> Dieter Maurer wrote:
>>> Then, we could get rid of the "{get|query}[Multi]Adapter" altogether
>>> and consistently use "I()" with appropriate optional  
>>> parameters --
>>> what a simplification and homogenization :-)
>>
>> Yeah, but since when has simplification or homogenisation been a  
>> goal of
>> Zope 3? ;-)
>
> It was with the "Service" geddon: make "Service" and "Utility"  
> homgogenous.

Indeed.

I've personally thought for some time that it would be quite nice if  
all you had to do was call an interface to look up a utility (which is  
sort of a multi-adapter of order 0) or to do some kind of adaption, no  
matter how many objects you wanted to adapt. E.g.:

   auth = IAuthentication() # utility
   auth = IAuthentication(default=None)
   langs = IUserPreferredLanguages(request) # adapter
   langs = IUserPreferredLanguages(request, default=None)
   view = IBrowserPage((obj, request), name='index')# named  
multi-adapter

etc.

Personally I would favour such consistency higher than the current  
behaviour, which may have been invented intentionally but still causes  
confusion once in a while.

___
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.testbrowser.testing.Browser has undefined dependencies

[Philipp von Weitershausen]

Chris Withers wrote:
> I'm just starting to play with zope.testbrowser's testing.Browser but I 
> notice that is uses the following packages:
> 
> transaction
> zope.app.testing
> zope.app.folder
> zope.app.component
> 
> ...but zope.testbrowser doesn't declare any dependency on these.

It does, using the "extras" mechanism you mention below.

> It probably should in some way, but I can see why it doesn't currently, 
> give nthat there are likely lots of zope.testbrowser users who have to 
> interested in zope.testbrowser.testing.Browser.
> 
> Is this something that we can solve with:
> http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies
> 
> If it is, I guess we would add an extra_requires to zoep.testbrowser's 
> setup.py with the packages listed above?

If you had a look at zope.testbrowser/setup.py, you'd notice

 extras_require = dict(
 test = ['zope.interface',
 'zope.schema',
 'zope.app.component',
 'zope.app.folder',
 'zope.app.testing',
 'zope.app.zcmlfiles',
 'zope.app.securitypolicy',
],
 ),

> Would the following then work in a buildout:
> 
> [test]
> recipe = zc.recipe.testrunner
> 
> eggs =
>  mypackage
>  zope.testbrowser[testing.Browser]

zope.testbrowser [test]

___
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.component: calling an Interface and calling queryAdapter give differing results

[Philipp von Weitershausen]

Shane Hathaway wrote:
> Chris Withers wrote:
>>  From a user's perspective, this makes no sense:
>>
>>  >>> from zope.interface import implements,Interface
>>  >>> from zope.component import queryAdapter
>>  >>> class ISomething(Interface): pass
>> ...
>>  >>> class MyClass: implements(ISomething)
>> ...
>>  >>> m = MyClass()
>>
>> Right, so this does make sense:
>>
>>  >>> ISomething(m)
>> <__main__.MyClass instance at 0x00BED6E8>
>>
>> This does not:
>>  >>> repr(queryAdapter(m,ISomething))
>> 'None'
> 
> Looks like a bug to me.  If the object passed as the first argument to 
> queryAdapter() implements the interface passed as the second argument, I 
> believe queryAdapter() should return the object, regardless of any 
> component registrations.

No, it's not a bug. This is in fact a feature (like it or not). 
{query|get}Adapter will always try to look up an adapter, whether or not 
the object provides the interface. So the behaviour Chris observed is 
indeed intended. I agree it could be documented better.
___
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] ZODB3 3.9.0-dev-r77011 egg?!

[Philipp von Weitershausen]

El 19 Aug 2008, a las 12:05 , Chris Withers escribió:
> Philipp von Weitershausen wrote:
>>> and why does buildout pick it over a stable release?
>> Because buildout, like easy_install, will pick the newest available  
>> version for a distribution. Fortunately, buildout has a prefer- 
>> stable option so that you can tell it to prefer stable over alpha/ 
>> beta/dev releases. Also, in any serious situtation you'd want to  
>> pin your versions, e.g. using the KGS [2] or a manual list.
>
> Okay, so how come zopeproject doesn't do any of these?

Because I haven't bothered to update it yet.

> I don't even know how to use the KGS - where would I find docs on  
> that?

It's just the standard buildout-extension feature that you can use to  
pull in a versions list from the web, e.g. the one I just pasted you  
in my previous email:

[buildout]
...
extends = http://download.zope.org/zope3.4/versions.cfg
versions = versions


See http://pypi.python.org/pypi/zc.buildout#multiple-configuration- 
files. Of course you could also just download the file and add it to  
your buildout.cfg verbatimly.

___
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] [zopeproject] ZODB3 specified, but ZODB3 3.9.0-dev-r77011 egg still attempted?!

[Philipp von Weitershausen]

Chris Withers wrote:
> Okay,
> 
> So I bumped into the ZODB3 3.9.0-dev-r77011 problem while trying to get 
> going with zopeproject.
> 
> zopeproject created a buildout.cfg in my test project, so I thought I'd 
> lock ZODB to 3.8.0 to prevent problems:
> 
> [buildout]
> develop = .
> parts = app test
> find-links = http://download.zope.org/distribution/
> newest = false
> eggs-directory = C:\Zope\buildout-eggs
> 
> [app]
> recipe = zc.recipe.egg
> eggs = HelloWorld
> zope.app.apidoc
> zope.app.securitypolicy
> z3c.evalexception>=2.0
> Paste
> PasteScript
> PasteDeploy
> interpreter = python
> 
> [versions]
> ZODB3 = 3.8.0
> 
> [test]
> recipe = zc.recipe.testrunner
> eggs = HelloWorld
> defaults = ['--tests-pattern', '^f?tests$', '-v']
> 
> This didn't work, buildout still tries to install 3.9.0-dev-r77011. Why?!

Because you're not doing it right. You invented a [versions] section but 
you still need to tell buildout to actually use that section as a 
versions declarations:

[buildout]
...
versions = versions

http://pypi.python.org/pypi/zc.buildout#repeatable-buildouts-controlling-eggs-used

> I also noticed that buildout from this .cfg doesn't seem to use the 
> latest versions of things. It's only using version 1.0.7 of zc.buildout, 
> not the 1.1.0 I'd expect.

Because it's running in non-newest mode (newest = false in [buildout]). 
bin/buildout -n will override that setting from the command line and run 
it in newest mode.

http://pypi.python.org/pypi/zc.buildout#newest-and-offline-modes

> Now, my understanding is that find-links adds 
> to the index rather than replaces it, so what's going on here?

This has nothing to do with it.
___
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] ZODB3 3.9.0-dev-r77011 egg?!

[Philipp von Weitershausen]

Chris Withers wrote:
> Why does the egg in the subject line exist

Because somebody made it and uploaded it to download.zope.org. It 
probably happened during the initial eggification period when we didn't 
have a solid release process [1].

> and why does buildout pick it over a stable release?

Because buildout, like easy_install, will pick the newest available 
version for a distribution. Fortunately, buildout has a prefer-stable 
option so that you can tell it to prefer stable over alpha/beta/dev 
releases. Also, in any serious situtation you'd want to pin your 
versions, e.g. using the KGS [2] or a manual list.


[1] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt
[2] http://download.zope.org/zope3.4/versions.cfg
___
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 Tests: 4 OK, 1 Unknown

[Philipp von Weitershausen]

Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Zope Tests Summarizer wrote:
>> Summary of messages to the zope-tests list.
>> Period Fri Aug 15 11:00:00 2008 UTC to Sat Aug 16 11:00:00 2008 UTC.
>> There were 5 messages: 5 from Zope Tests.
>>
>>
>> Unknown
>> ---
>>
>> Subject: UNKNOWN : Zope-2.8 Python-2.3.6 : Linux
>> From: Zope Tests
>> Date: Fri Aug 15 20:40:07 EDT 2008
>> URL: http://mail.zope.org/pipermail/zope-tests/2008-August/010015.html
> 
> I can't reproduce this failure on my box (self-compiled Python 2.3.5,
> Ubuntu).  Does anyone have a clue why the 'encodings.aliases' module
> would be different?

I certainly don't, but apparently there was a bug report [1] which 
caused Andreas to fix it in Hotfix (see r89881), but not the Zope 2.8 
branch.

[1] https://bugs.edge.launchpad.net/zope2/+bug/258154
___
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.app.form: Make "no value" always available?

[Philipp von Weitershausen]

Thomas Lotze wrote:
> zope.app.form items edit widgets don't provide the "no value" value if
> the corresponding field is required. While this prevents invalid input, it
> means that e.g. a drop-down box may then have one of the valid values
> pre-selected. If user forgets to change that value, he could save the form
> without noticing that the default value is implicitly selected, which may
> be completely wrong.
> 
> In some cases it would be preferrable for the widget to default to a "no
> value" value even if the field is required so the form won't validate if
> the user doesn't consciously select a value. One of our customers asked
> for this behaviour, for example. If noone objects, we'd like to change
> zope.app.form accordingly.

+1, but perhaps for required fields we shouldn't say "(no value)", we 
should say "(select a value)".
___
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] Re: zope.app.authentication and zope.app.container broken doctests

[Philipp von Weitershausen]

Wichert Akkerman wrote:
I've re-tagged and reuploaded new versions zope.app.container 3.5.6 and 
zope.app.authentication 3.4.3. This should be ok.


Re-uploading is very problematic: if anyone has the previous version in
their buildout download cache they will never get the new version. I
prefer a minor version number bump instead of re-uploading.


That's what Christophe did. His choice of words is just a bit confusing.
___
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] Re: zcml filtering

[Philipp von Weitershausen]

El 6 Aug 2008, a las 17:17 , Roger Ineichen escribió:

I'm +1 on zc.configuration.

z3c.unconfigure, however, will contain zope.component
specific code to "unconfigure" subscribers (which currently
have no useful discriminator). So it's a hack to make it work
with existing Zope code out there. If zope.component.zcml
were changed to emit useful actions for  (and
, too!), we could solely rely on shooting down
actions and the code could find its way into
zope.configuration. That will only help us with future Zope
code, not with existing code out there (which this is for).

Feel free to undertake this :)


That's a good argument but valid for any development or improvment
on existing code/packages.


It's about being pragmatic. We need to this to work on existing code  
(Zope 3.3 to be exact). We can't just upgrade zope.configuration.



The bad thing is that we now have 3 packages for one thing
doing right.


It's unfortunate, but things could be worse.


I'm +1 too for a simple zope.configuration package which offers
the API for doing configuration how it should.

What do you think about to release z3c.unconfigure and merge it
to zope.configuration after the release. So we have both options
and a simple setup for the future.


Not forgetting to give  and  decent  
discriminators.


But yes, that sounds like a great idea. Feel free to do it ;). I  
probably won't have time to worry about this any time soon. I'm just  
trying to fix an issue at hand.


___
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] Re: zcml filtering

[Philipp von Weitershausen]

El 6 Aug 2008, a las 16:47 , Stephan Richter escribió:

On Wednesday 06 August 2008, Philipp von Weitershausen wrote:
I'm working on a package for this functionality in z3c.unconfigure  
right
now. Name inspired by Martin's suggestion above; my original  
prototype

used had a different name but this is much better :).


Couldn't we just merge zc.configuration and z3c.unconfigure into
zope.configuration? Everyone who wants to use our configuration system
certainly wants this functionality as well.



I'm +1 on zc.configuration.

z3c.unconfigure, however, will contain zope.component specific code to  
"unconfigure" subscribers (which currently have no useful  
discriminator). So it's a hack to make it work with existing Zope code  
out there. If zope.component.zcml were changed to emit useful actions  
for  (and , too!), we could solely rely on  
shooting down actions and the code could find its way into  
zope.configuration. That will only help us with future Zope code, not  
with existing code out there (which this is for).


Feel free to undertake this :)

___
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] Re: zcml filtering

[Philipp von Weitershausen]

Marius Gedminas wrote:

On Tue, Aug 05, 2008 at 10:36:30PM +0100, Martin Aspeli wrote:
Subscribers and subscription adapters are particularly bad in this way, 
since they are unnamed and thus can't be "overridden", only amended to.


We've talked about an "off" switch for ZCML before. Given that we have a 
configuration machine that's capable of doing overrides based on 
discriminators, why couldn't we have support for negatives, e.g.



   


This could use a special _context that would record callables and 
discriminators, and then look for the corresponding 
callables/discriminators in the real context and remove them before that 
context was configured.


Subscribers don't have discriminators, unfortunately.


Indeed they don't. That just makes them harder to track down, though.

I'm working on a package for this functionality in z3c.unconfigure right 
now. Name inspired by Martin's suggestion above; my original prototype 
used had a different name but this is much better :).

___
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] Please no version numbers in setup.py [was: SVN: Zope2.buildout/tags/2.11.1/setup.py Pin / fix up dependencies based on comparison with monolith.]

[Philipp von Weitershausen]

Tres Seaver wrote:

Log message for revision 89399:
  Pin / fix up dependencies based on comparison with monolith.



Thanks for picking this up!

I do, however, strongly object to pinning versions of dependencies in 
setup.py like this. What's the point of eggifying Zope 2 in the first 
place then if not for the ability to upgrade individual libraries to 
newer versions with bugfixes or features?


Instead of pinning versions in setup.py, we should rather include a list 
of known-good versions, or even better, add the Zope 2 eggs to the Zope 
KGS. That way, by default, you'd get the known good set but you could 
deviate from it as necessary. More importantly, by having one good set 
(instead of a setup.py here, a versions.cfg there and another list 
somewhere else), the KGS becomes much easier to maintain.


Philipp



+  install_requires=['Acquisition==2.11.1',
+'DateTime==2.11.1',
+'docutils==0.4.0',
+'ExtensionClass==2.11.1',
+'Interface==2.11.1',
+'Persistence==2.11.1',
+'pytz==2007f', # latest is fine?
+'RestrictedPython==3.4.2',
+'StructuredText==2.11.1',
+'tempstorage==2.11.1',
+'ZConfig==2.5.1',
+'zLOG==2.11.1',
+'zdaemon==2.0.1',
+'ZODB3==3.8.0',
+'zodbcode==3.4.0',
+'zope.annotation==3.4.0',
+'zope.cachedescriptors==3.4.0',
+'zope.component==3.4.0',
+'zope.configuration==3.4.0',
+'zope.contentprovider==3.4.0',
+'zope.contenttype==3.4.0',
+'zope.copypastemove==3.4.0',
+'zope.datetime==3.4.0',
+'zope.decorator==3.4.0',
+'zope.deferredimport==3.4.0',
+'zope.deprecation==3.4.0',
+'zope.documenttemplate==3.4.0',
+'zope.dottedname==3.4.0',
+'zope.dublincore==3.4.0',
+'zope.error==3.5.1',
+'zope.event==3.4.0',
+'zope.exceptions==3.4.0',
+'zope.filerepresentation==3.4.0',
+'zope.formlib==3.4.0',
+'zope.hookable==3.4.0',
+'zope.i18nmessageid==3.4.0',
+'zope.i18n==3.4.0',
+'zope.index==3.4.0',
+'zope.interface==3.4.0',
+'zope.lifecycleevent==3.4.0',
+'zope.location==3.4.0',
+'zope.minmax==3.4.0',
+'zope.modulealias==3.4.0',
+'zope.pagetemplate==3.4.0',
+'zope.proxy==3.4.0',
+'zope.publisher==3.4.0',
+'zope.rdb==3.4.0',
+'zope.schema==3.4.0',
+'zope.security==3.4.0',
+'zope.sequencesort==3.4.0',
+'zope.sendmail==3.4.0',
+'zope.server==3.4.0',
+'zope.session==3.4.0',
+'zope.size==3.4.0',
+'zope.securitypolicy==3.4.0',
+'zope.structuredtext==3.4.0',
+'zope.tales==3.4.0',
+'zope.tal==3.4.0',
+'zope.testbrowser==3.4.0',
+'zope.testing==3.4.0',
+'zope.thread==3.4.0',
+'zope.traversing==3.4.0',
+'zope.viewlet==3.4.0',
+'zope.wfmc==3.4.0',
+'zope.app.annotation==3.4.0',
+'zope.app.apidoc==3.4.3',
+'zope.app.applicationcontrol==3.4.1',
+'zope.app.appsetup==3.4.1',
+'zope.app.authentication==3.4.1',
+'zope.app.basicskin==3.4.0',
+'zope.app.broken==3.4.0',
+'zope.app.cache==3.4.0',
+'zope.app.component==3.4.1',
+'zope.app.container==3.5.3',
+'zope.app.content==3.4.0',
+#'zope.app.content_types==3.4.0',   XXX
+'zope.app.debug==3.4.0',
+'zope.app.dependable==3.4.0',
+'zope.app.error==3.5.1',
+#'zope.app.event==3.4.0',   XXX
+'zope.app.exception==3.4.1',
+'zope.app.file==3.4.2',
+

[Zope-dev] Re: configuring global utilities in zcml

[Philipp von Weitershausen]

Chris Withers wrote:

Nikolay Kim wrote:
I'm aware of this but it kind of defeats the idea of seperating code 
and   configuration...


So, other ideas?


create new zcml directive.


That seems pretty heavyweight :-/


It's not. It's in fact relatively easy to write a custom utility 
directive that takes arbitrary parameters and then passes them on to the 
utility's factory.


The question is whether that's a good idea. I don't think it is. Either 
the parameters you want to pass have to do with code, then ZCML isn't 
the right *tool* because from ZCML you can only pass Unicode strings 
(for arbitrary parameters, ZCML can't do its magic of resolving dotted 
names or validating or whatever).


Or the parameters you want to pass have to do with configuration (e.g. 
some server name, a port, a directory, etc.). Then ZCML isn't the right 
*place*. An admin-friendy place (zope.conf, paste.ini, custom 
configuration file, etc.) would be a much better place. Or make it a 
local persistent utility that stores its configuration persistently and 
allows it to be changed TTW.

___
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] Re: configuring global utilities in zcml

[Philipp von Weitershausen]

Chris Withers wrote:

Nikolay Kim wrote:

you can create utility in python file and then use component=""

for example utility.py:

class Utility(object):
  pass

myUtility = Utility()


configure.zcml:




I'm aware of this but it kind of defeats the idea of seperating code and 
 configuration...


What kind of configuration are we talking about here? I personally think 
that ZCML is great for switching on and off software components and then 
perhaps configuring a few software-related aspects about them (e.g. 
security protections). But IMHO ZCML is the wrong tool to configure, 
say, database connections or SMTP server settings for outgoing email. 
Because this isn't configuring software, it's configuring settings *for* 
software.


I personally therefore prefer to make settings like those configurable

a) either in zope.conf (there's an easy way to have to custom settings 
in zope.conf read by your utilities, see zope.app.appsetup.product


b) or TTW by implementing the utility in question as a local utility and 
then writing browser pages for it.


I'm all for separating code and configuration, but I'm also all for 
separating admin configuration from developer configuration. I don't 
think an admin should ever have to edit ZCML (and yes, I do realize that 
this wasn't the initial vision, but let's face it, ZCML is a developer 
tool).


Or, if I take Grok: the developer writes Python, the admin writes some 
other form of configuration, be it zope.conf, paste.ini or TTW 
configuration in a browser.

___
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] Re: bad "zope.size" to remove from PyPI

[Philipp von Weitershausen]

El 2 Aug 2008, a las 17:45 , Chris Withers escribió:

Benji York wrote:
In case anybody's wondering how this complies with our "no removal  
of any
release whatsoever" policy [1], be assured that a 3.4dev-r73090  
thing isn't
a release by our standards. This version number not only contains  
the 'dev'
marker, meaning it must have come from a development branch  
(possibly the
trunk), it also contains the -rXXX suffix meaning it was made  
right from a
subversion checkout without having created a tags first (why else  
would you

want to include the revision number).
Still, it's likely that someone was using it and their buildouts  
are now
broken.  We should have instead generated a proper release with a  
higher

version number and left the dev release alone.


This is silly.

Mistakes happen. Buildout and/or setuptools should be tolerant of  
accidental releases that are then removed from PyPI.


What currently happens in cases like this?


Nothing. It's only a problem if somebody pinned zope.size version to  
3.4dev-r73090 in their buildout.cfg. But that's their own fault IMHO  
because it's clearly not a release.___

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] Re: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation

[Philipp von Weitershausen]

Christophe Combelles wrote:

Stephan Richter a écrit :

On Friday 01 August 2008, Christophe Combelles wrote:
Did you miss the CHANGES.txt in zope.release ? We have two histories 
now.


Nope, but that file tracks the package -- source code -- changes of 
zope.release.


I wanted a separate file that tracks the changes to the 
controlled-packages.cfg file.


In my understanding, there is almost no source code in 'zope.release', 
since it has been moved into 'zope.kgs'. So there should be very few 
entries in CHANGES.txt, and I'm not sure there is a real interest in 
having two separate files. In my opinion, it adds confusion, people are 
more used to maintain CHANGES.txt.


Exactly.

The other problem is there is no tag for c1, c2, c3 and c4. I thought 
zope.release was meant to represent the release number of zope.


I would tend to:
- create a tag for all missing candidates
- merge KGS-HISTORY.txt into CHANGES.txt and recover missing information 
from published control-packages.cfg


+1
___
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] Re: bad "zope.size" to remove from PyPI

[Philipp von Weitershausen]

Christophe Combelles wrote:

could someone remove this package from the PyPI :
http://pypi.python.org/pypi/zope.size/3.4dev-r73090

This is an empty development version, considered more recent by PyPI 
than the latest released version 3.4.0. (which is r78211)


Done.

In case anybody's wondering how this complies with our "no removal of 
any release whatsoever" policy [1], be assured that a 3.4dev-r73090 
thing isn't a release by our standards. This version number not only 
contains the 'dev' marker, meaning it must have come from a development 
branch (possibly the trunk), it also contains the -rXXX suffix meaning 
it was made right from a subversion checkout without having created a 
tags first (why else would you want to include the revision number).



[1] 
http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt

___
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] Re: Running the 3.4 KGS tests: 9 fail, 6 errors

[Philipp von Weitershausen]

Shane Hathaway wrote:

Marius Gedminas wrote:

I think I'll run the test suite again on a 64-bit Linux machine, for
extra fun.  And maybe do that for Python 2.4 as well.


zope.proxy and related modules failed badly under 64 bit Python 2.5 
until I fixed the C code on the trunk 2 weeks ago, however, I don't 
think my changes landed in the KGS.  I also fixed broken tests.  Should 
I backport my changes?  I don't know whether a release is planned soon.


Hey Shane,

thanks for those fixes! I've just made the necessary backports and 
tagged the following releases:


zope.proxy 3.4.2
zope.security 3.4.1
zope.security 3.5.2
zope.app.container 3.5.5

I haven't uploaded them to PyPI yet because a) I don't have the rights 
to all of them and b) they have extension modules which means we should 
simultaneously release Win32 binaries (which I can't). I've therefore 
CC'ed Jim, hoping that he could upload the sdist tarballs and the binary 
eggs for Windows.


Jim?

Thanks,
Philipp
___
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] Re: Utility factory handling for zope.component

[Philipp von Weitershausen]

Wichert Akkerman wrote:

Stephan Richter wrote:

On Wednesday 23 July 2008, Wichert Akkerman wrote:
  

If there are no objections I intend to merge the branch to trunk in a
few days



I am uncomfortable with the way you approached this. I think there are at 
least two other possibilities that I can see without having looked closer:


1. Use the info object. The point of the info is to contain this sort of 
information.
  


Which info object are you referring to? The only information I could see 
for utility registration is a tuple, not an object. This is used to 
build the UtilityRegistration object when querying registration 
information, and I added a factory method there.


I think Stephan is referring to the (formerly) last item of the tuple, 
which is available as utility_reg.info. It contains information about 
how the component was registered, for instance the ZCML file name + line 
number.


It looks like Stephan is suggesting to do something like this:

  component = factory()
  registry.registerUtility(component, info=InfoAbout(factory))

whereas Wichert's approach allows you to write:

  registry.registerUtility(factory=factory)

I prefer Wichert's approach.
___
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] Please use 'svn mv'

[Philipp von Weitershausen]

I would like to remind everyone that when you do refactorings and move 
code around, to please use 'svn mv' or 'svn cp'. For instance, when you 
split a large file into two smaller ones, use 'svn cp' to create the 
second file and then remove stuff from it that doesn't go there. That 
way, version history isn't lost for neither parts of the code. The same 
goes for splitting up packages (moving components into a library 
package, for instance).


Thanks.

___
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] Re: No events in zope.annotation

[Philipp von Weitershausen]

Stephan Richter wrote:

On Tuesday 15 July 2008, Fred Drake wrote:

On Tue, Jul 15, 2008 at 12:30 PM, Stephan Richter

<[EMAIL PROTECTED]> wrote:

Thus I propose:

- Add ObjectCreatedEvent event notification to zope.annotation factory
call.

By this, I presume you mean the stuff in zope.annotation.factory; is that
right?


Yes.


In our group, we've decided to avoid that machinery.  It causes the
separation between data and code to become excessively blurred.  I'd
love to see that factory machinery become unused.  I definitely
consider it unusable.


I use it all the time. I think it makes development a lot easier.


I agree.

In fact, 
this came out of the ST project, where we constantly repeated this sort of 
code.


Not that it matters much, but I think it was Martijn Faassen who wrote it.


BTW, I really do not understand how it blurs the separation of code and data.


Me neither.

___
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] Re: No events in zope.annotation

[Philipp von Weitershausen]

Stephan Richter wrote:

Hi everyone,

I just tried to create a catalog for an annotation and noticed that it does 
not get filled. Digging around in the zope.annotation package, I noticed that 
the zope.annotation package does not send out any object events. This 
sucks. ;-)


Thus I propose:

- Add ObjectCreatedEvent event notification to zope.annotation factory call.


+0


- Add ObjectAddedEvent to attribute annotations __setitem__.

- Add ObjectRemovedEvent to attribute annotations __delitem__.


-1. As Fred said, these events are specific to containers (as in 
IContainer). IAnnotation adapters aren't containers and annotation 
objects aren't contained in them (as in IContained).


___
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] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond

[Philipp von Weitershausen]

Tres Seaver wrote:

Mark Hammond wrote:

Well, Zope moved onwards from PAS to PAU


I doubt that seriously:  I would venture that there are two orders of
magnitude more users of PAS than PAU in production deployments.  PAU was
an attempt to port the PAS to a "component-centric" implementation, but
it lost at least a couple of key features along the way:  most notably,
the ZCA provides no way to control the ordering of the invocation of the
plugins.


The ZCA may have no built-in way to control the ordering, but PAU surely 
does control the ordering. It keeps an ordered list of plugin names. 
These plugins can either be contained items in the PAU (like in PAS) or 
utilities for ICredentialsPlugin or IAuthenticatorPlugin.


___
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] Re: how many checkin lists?!

[Philipp von Weitershausen]

Chris Withers wrote:

Hi All,

Just me, or is it excessive that we have:

http://mail.zope.org/pipermail/zope3-checkins/


This one is obsolete now.


http://mail.zope.org/pipermail/zope-checkins/


This one is for Zope 2 only.


http://mail.zope.org/pipermail/checkins/


This one covers the whole repository.


...and maybe more I don't know about?

Surely one list would suffice?


I think so.

___
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] Re: PAULA: bringing Zope 3's authentication to Plone and beyond

[Philipp von Weitershausen]

Wichert Akkerman wrote:

Previously Philipp von Weitershausen wrote:

Wichert Akkerman wrote:

Previously Florian Friesdorf wrote:

Hi *,

within the scope of google summer of code I am integrating zope 3's PAU with
Plone's PAS and further enable (non-AT) content objects as source for users and
groups. All functionality is developed in pure zope3, the plone integration is
happening in a separate packages.

All documents describing the project, as well as links to the code can be found
here:

https://chaoflow.net/projects/gsoc2008/z3membrane-ldap

The one thing I am missing is: why? PAS works fine and covers a lot more
functionality than PAU and there are more PAS plugins than PAU plugins.
It's also perfectly possible to use non-AT content as source for users
with PAS as well as tools such as b-org demonstrate.
Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert 
is right. To be constructive, I think it'd be much more interesting to 
investigate hooking Plone up to an external authentication mechanism 
such as repoze.who.


Doesn't repoze already have a PAS plugin to do just that?


Ah, that's right: http://svn.agendaless.com/Products.whoopass. That 
doesn't mean it could be integrated better, though, for instance UI-wise...


___
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] Re: [Plone-developers] PAULA: bringing Zope 3's authentication to Plone and beyond

[Philipp von Weitershausen]

Wichert Akkerman wrote:

Previously Florian Friesdorf wrote:

Hi *,

within the scope of google summer of code I am integrating zope 3's PAU with
Plone's PAS and further enable (non-AT) content objects as source for users and
groups. All functionality is developed in pure zope3, the plone integration is
happening in a separate packages.

All documents describing the project, as well as links to the code can be found
here:

https://chaoflow.net/projects/gsoc2008/z3membrane-ldap


The one thing I am missing is: why? PAS works fine and covers a lot more
functionality than PAU and there are more PAS plugins than PAU plugins.
It's also perfectly possible to use non-AT content as source for users
with PAS as well as tools such as b-org demonstrate.


Exactly. I don't mean to pee on anybody's parade here, but IMHO Wichert 
is right. To be constructive, I think it'd be much more interesting to 
investigate hooking Plone up to an external authentication mechanism 
such as repoze.who.


___
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] Re: Zope3 installation on windows - how?

[Philipp von Weitershausen]

Hermann Himmelbauer wrote:

And there's once again this mingw32 problem.

4) Next, I tried zopeproject:
$ easy_install zopeproject
$ zopeproject HelloWorld

First, zopeproject does not install the packages into the Python 
site-packages,


That's *intended*. That's, in fact, much better than stuffing about a 
100 eggs into site-packages...


What can I do? Is there perhaps some precompiled Windows distribution for 
Zope-3.4 available?


All Zope 3.4 packages that have C extensions are available as Windows 
binaries, though perhaps not in all versions. The versions in the KGS 
should all be available as Windows binaries, though. Just include 
http://download.zope.org/zope3.4/versions.cfg in your buildout.cfg.


___
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] Re: SVN: zope.app.container/trunk/CHANGES.txt Added release note

[Philipp von Weitershausen]

Roger Ineichen wrote:

Log message for revision 88121:
  Added release note

Changed:
  U   zope.app.container/trunk/CHANGES.txt

-=-
Modified: zope.app.container/trunk/CHANGES.txt
===
--- zope.app.container/trunk/CHANGES.txt2008-07-08 17:45:53 UTC (rev 
88120)
+++ zope.app.container/trunk/CHANGES.txt2008-07-08 17:46:50 UTC (rev 
88121)
@@ -2,6 +2,13 @@
 CHANGES
 ===
 
+

+Heads up:
+
+Relase zope.app.authentication 3.4.2 if this 3.6.1 get released. It contains a 
+bugfix based on the BTreeContainer re-implementation.

+
+


I think this it can be released now. The fix you applied was needed 
either way, if I'm correct. GroupFolder's __init__ was not calling its 
own super's __init__ but the super __init__ of BTreeFolder. This should 
have worked before and after the changes in zope.app.container 3.6.x.


Of course, it'd be good to test this with both zope.app.container 3.5.x 
and 3.6.x first :)


___
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] Re: buildout on Windows

[Philipp von Weitershausen]

Martin Aspeli wrote:

Chris Withers wrote:

Hey All,

I'm trying to run a plone-ish buildout on Windows for a customer, 
currently getting this:


creating zope.proxy
copying zope/proxy\proxy.h -> zope.proxy
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible 
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin 
installed,

you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
While:
   Installing zope2.

Do binary eggs exist for zope.proxy and friends?
If not, how do I build 'em and upload them for others to use?

If they do exist, how do I get buildout to use them rather than trying 
to build from source on my system?


buildout will use binary eggs if they exist and match the version spec, 
so you may want a [version] block. However:


 - if you really are installing zope2, then I wonder why it's trying to 
download zope.proxy.


It's not, it's just compiling Zope 2 which contains zope.proxy. From my 
initial reply to Chris:


  This isn't a matter of a binary zope.proxy egg. If you look at the
  'zope2' part of your buildout.cfg, you'll see it's actually trying to
  compile Zope 2 itself (which happens to contain the zope.proxy package
  as part of the Zope 3 libraries that it ships with).

___
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] Re: buildout on Windows

[Philipp von Weitershausen]

El 21 Jun 2008, a las 20:15 , Chris Withers escribió:

Philipp von Weitershausen wrote:
This isn't a matter of a binary zope.proxy egg. If you look at the  
'zope2' part of your buildout.cfg, you'll see it's actually trying  
to compile Zope 2 itself (which happens to contain the zope.proxy  
package as part of the Zope 3 libraries that it ships with).


Right, this doesn't seem sane.

Is this the fault of the recipe or of buildout?


zc.buildout is a generic deployment tool. It's not related to Zope in  
any specific way (other than that it shares a couple of contributors).  
You can think of zc.buildout as 'make'. It just does what you tell it  
to do. buildout.cfg is the zc.buildout's "Makefile".


As I said, if you look at *your* specific buildout.cfg, you'll see  
that it tells zc.buildout to compile Zope 2. This is not a faulty  
zc.buildout presetting (because zc.buildout is a generic tool).


What you want to do on Windows is install Zope 2 manually using the  
installers, then edit buildout.cfg to NOT build Zope 2, but to  
refer to the installation location, e.g.:


Well, I really don't ;-) I want buildout to get binary eggs on windows


Zope2 isn't eggified yet, so it can't be installed as eggs.

or (and I know I'm asking  a lot here) to get a binary Zope 2 if it  
needs one.


Then you want to

a) either write a recipe that does just that
b) or extend the plone.recipe.zope2install recipe to get the binary  
Zope installer and execute it (if that's even possible) on Windows,  
rather than trying to get the source tarball and compile it (this  
would still be the default for Unixy platforms).


Option b) is probably preferred because then you can share the same  
buildout.cfg between different platforms.


I'm still hazy on what the problem is... Will buildout use binary  
eggs if they're available? (given that it's Windows where this is  
particularly important...)


Yes, buildout just uses setuptools to fetch and install eggs. But as  
said, Zope 2 isn't eggified yet, so there's no point debating what  
kind of eggs it should have gotten. Your buildout.cfg never told it to  
get an egg. Your buildout.cfg tells it to compile and install Zope 2.


___
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] Re: buildout on Windows

[Philipp von Weitershausen]

Chris Withers wrote:

Hey All,

I'm trying to run a plone-ish buildout on Windows for a customer, 
currently getting this:


creating zope.proxy
copying zope/proxy\proxy.h -> zope.proxy
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible 
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin 
installed,

you can try compiling with MingW32, by passing "-c mingw32" to setup.py.
While:
  Installing zope2.

Do binary eggs exist for zope.proxy and friends?


This isn't a matter of a binary zope.proxy egg. If you look at the 
'zope2' part of your buildout.cfg, you'll see it's actually trying to 
compile Zope 2 itself (which happens to contain the zope.proxy package 
as part of the Zope 3 libraries that it ships with).


What you want to do on Windows is install Zope 2 manually using the 
installers, then edit buildout.cfg to NOT build Zope 2, but to refer to 
the installation location, e.g.:


  [zope2]
  location = C:\Path\to\my\zope2
  # nothing else here, also remove 'zope2' from buildout:parts

  [instance]
  ...
  # stays the same:
  zope2-location = ${zope2:location}
  ...

___
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] Re: View component registration

[Philipp von Weitershausen]

Martijn Faassen wrote:
One question is what to do for persistent registrations in local sites. 
I don't imagine they're used a lot, but it'd mean a content upgrade to 
re-register them, right?


The only piece of software that, to my knowledge, can actually *make* 
local view registrations is five.customerize. Plone uses it to allow 
local customization of Zope 3 views and viewlets. I suppose they'll just 
have to write an upgrade script (after having update five.customerize 
itself).


___
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] Re: View component registration

[Philipp von Weitershausen]

David Glick wrote:


On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote:


Martijn Faassen wrote:
There's one major problem that I see. What's the backwards 
compatibility story? I'm sure there are a lot of cases in lots of 
code where people look up views with a getMultiAdapter, and if we 
started registering views differently, wouldn't that code break? How 
to we get from A to B?


It deserves consideration, but I don't think code will be prone to 
break since we're merely providing more information to lookup a view 
component, not less.


Exactly.  The interface passed to getMultiAdapter or queryMultiAdapter 
is a minimum requirement.  Making views provide IView won't stop them 
from providing Interface, which is the default.


Well, true, view *lookup* for Interface will still work if we register 
views for a more specific interface. But if Zope's browser publication 
now starts looking up views with the more specific interface and there 
are still views around that haven't been registered for that but for 
Interface, we'll run into backward compatibility problems.


I suppose the browser publication would have to be smart about it and do 
a legacy lookup for Interface if it can't find a view for the specific one.


Either way, it's not *that* simple...
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce

http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Re: View component registration

[Philipp von Weitershausen]

Malthe Borch wrote:
Currently views are registered as components providing 
zope.interface.Interface; this is unfortunate since other kinds of 
components may use the same specification, namely (context, request).


An example of this is ``IAbsoluteURL``; it clashes with the resources 
view*.


In the words of Christian Theune: "I think it looks like one should 
never ask for adaptions to Interface."


I suggest we then register views as components providing 
``zope.component.IView``; browser views should provide 
``zope.publisher.interfaces.browser.IBrowserView``.


IBrowserView is IMHO not the right one. Anything, including absolute_url 
and standard_macros, can be a browser view. But browser views aren't 
necessarily *publishable*. In other words, Zope 3 won't resolve URLs 
like http://localhost:8080/standard_macros or 
http://localhost:8080/absolute_url. (Zope 2 will publish such URLs which 
is quite terrible).


Browser pages (as opposed to browser views) are components that *are* 
publishable on the other hand. That's because they provide 
IBrowserPublisher (IBrowserPage extends this interface). That's why I 
think IBrowserPage is the right interface to adapt to. But perhaps it 
should be something else, though either way it should be based on 
IBrowserPublisher.


___
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] Re: View component registration

[Philipp von Weitershausen]

Jim Fulton wrote:


On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote:

Currently views are registered as components providing 
zope.interface.Interface; this is unfortunate since other kinds of 
components may use the same specification, namely (context, request).


Right. This is a historical accident that I would love to see 
corrected.  It's just never been a high enough priority.


...

Note that resources have the same problem.

I suggest we then register views as components providing 
``zope.component.IView``; browser views should provide 
``zope.publisher.interfaces.browser.IBrowserView``.



zope.component isn't the right place.  What's more, "View" isn't the 
right word.


I think this needs more thought, but I think that:

- the interface is about publication (not components or views)

- the interface is for objects that want to be published, regardless of 
whether they are adapters.


Basically, when you get to the end of URL traversal, you should get an 
object that wants to be called to get a result and that implements or 
can be adapted to this interface.


Right. I think zope.publisher.interface.browser.IBrowserPage already 
fits this description, but feel free to correct me if I'm wrong.


___
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] Re: git mirror of svn://svn.zope.org/repos/main ?

[Philipp von Weitershausen]

Jeff Kowalczyk wrote:

I was going to ask this question anyway, but perhaps it's more timely with
the scheduled server move:

Has anyone made a git clone of svn://svn.zope.org/repos/main suitable for
public mirroring on github, etc.?


Not that I know of, but there's a read-only SVN mirror: http://svn.zope.de

___
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] Re: buildbot failure in Zope on zope.app.zptpage

[Philipp von Weitershausen]

Here, the same thing as with zope.pagetemplate happened. zope.tal no 
longer emits a trailing newline character. Fixed on the trunk.



[EMAIL PROTECTED] wrote:

The Buildbot has detected a new failure of zope.app.zptpage on Zope.
Full details are available at:
 http://zopebuildbot.whq.gocept.com/zope.app.zptpage/builds/95

Buildbot URL: http://zopebuildbot.whq.gocept.com/

Buildslave for this Build: local

Build Reason: The Nightly scheduler named 'zope.app.zptpage nightly' triggered 
this build
Build Source Stamp: [branch zope.app.zptpage/trunk] HEAD
Blamelist: 


BUILD FAILED: failed test
Logs are attached.

sincerely,
 -The Buildbot





___
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] Re: buildbot failure in Zope on zope.app.twisted

[Philipp von Weitershausen]

zope.app.twisted was missing a test dependency (zope.testbrowser) for a 
level 2 test. Fixed now.



[EMAIL PROTECTED] wrote:

The Buildbot has detected a new failure of zope.app.twisted on Zope.
Full details are available at:
 http://zopebuildbot.whq.gocept.com/zope.app.twisted/builds/97

Buildbot URL: http://zopebuildbot.whq.gocept.com/

Buildslave for this Build: local

Build Reason: The Nightly scheduler named 'zope.app.twisted nightly' triggered 
this build
Build Source Stamp: [branch zope.app.twisted/trunk] HEAD
Blamelist: 


BUILD FAILED: failed test
Logs are attached.

sincerely,
 -The Buildbot





___
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] Re: buildbot failure in Zope on zope.pagetemplate

[Philipp von Weitershausen]

These failures are due to recent changes to zope.tal (3.5.0) in which 
the TAL interpreter no longer emits a trailing newline character (and 
thus finally complies with its own spec).


I've fixed this on the zope.pagetemplate trunk now.


[EMAIL PROTECTED] wrote:

The Buildbot has detected a new failure of zope.pagetemplate on Zope.
Full details are available at:
 http://zopebuildbot.whq.gocept.com/zope.pagetemplate/builds/92

Buildbot URL: http://zopebuildbot.whq.gocept.com/

Buildslave for this Build: local

Build Reason: The Nightly scheduler named 'zope.pagetemplate nightly' triggered 
this build
Build Source Stamp: [branch zope.pagetemplate/trunk] HEAD
Blamelist: 


BUILD FAILED: failed test
Logs are attached.

sincerely,
 -The Buildbot





___
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] Re: Deciphering Zope Comments

[Philipp von Weitershausen]

Shane Hathaway wrote:

Hi all,

I'm trying to get a handle on Zope 3.  I plan to take a bunch of Zope 3 
modules and combine them in a new way.  The goal is to create for myself 
a comfortable working environment that lets me run simple code in a 
small mod_wsgi environment with easy reloading and no ZODB initially.


To achieve this, I need to understand what's going on in the Zope 3 code 
base.  While the code itself is easy to understand, there are many 
comments in the code that suggest changes are coming soon.  Please help 
me figure out what is meant by these comments.


The first cryptic comment comes from zope.component.  The _api module 
starts with this gem:


# SiteManager API. This needs to get deprecated eventually.


I think this meant to say that the word "Site Manager" has been 
deprecated. Nowadays we just say component registry. In theory. I think 
we just found that renaming things isn't worth all the trouble.


But... um... everything in the module uses getSiteManager().  The whole 
component foundation is built on it.  When is it going to be replaced? 
With what?  By whom?


I think the comment can go. It's the opposite of useful right now.

I'm assuming for the moment that the comment is a lie, and that 
getSiteManager() is not going away, since otherwise I have no foundation 
to build upon.


Yup.

I think I want to use a threading.local as my site manager.  That way, I 
can use a different configuration for each WSGI app even if several apps 
run in different threads of a single Python interpreter.  It looks like 
the zope.app.component.hooks module does something like what I want, but 
that module is complicated and lacks comments in the places that matter, 
so I'm not quite sure what it accomplishes.  I'll add comments to that 
module if anyone can explain it fully.


zope.component.getSiteManager() is a "hooked" function (using 
zope.hookable). That means it can be replaced by some other 
implementation. zope.app.component.hooks makes use of that. It replaces 
zope.component.getSiteManager() with an implementation that looks up a 
thread local variable (SiteInfo). This replacement is done in the 
setHooks() function which is called some time during Zope startup.


That led me to the zope.thread module, which is apparently deprecated 
already, yet zope.app.component still depends on it.  Is that an 
hysterical accident?


As said previously, zope.thread.local is just a wrapper around Python's 
threading.local module (which was contributed by Jim based on 
zope.thread.local).


___
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] Re: Buildout parameter parsing

[Philipp von Weitershausen]

Malthe Borch wrote:
I think a valuable extension to the parameter parsing in buildout's 
configuration language would be to allow += and -= operators, which 
would append and remove items, respectively.


Example:

[instance]
eggs += Products.PDBDebugMode

Singular or plural arguments would be supported.

\malthe


This isn't the buildout list :). I think buildout matters are discussed 
on the distutils SIG mailinglist. There's also an issue tracker at 
https://edge.launchpad.net/zc.buildout.

___
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] Re: Five registerPackage results in unresolved ConflictError

[Philipp von Weitershausen]

Believe something very very rotten in Five's registerPackage was fixed 
by Rocky in r72986 [1]. As far as I can tell this was never merged to 
the 1.4 branch, but I could we wrong.



[1] http://svn.zope.org/?rev=72986&view=rev


Sasha Vincic wrote:

Forgot to say that this is Zope 2.9.8, Five 1.4 branch from svn, Plone 2.5.5

/Sasha

On Fri, May 16, 2008 at 12:03 PM, Sasha Vincic <[EMAIL PROTECTED] 
> wrote:


Hi

On a server we have a ZEO server with 6 clients. When we
start/restart the server we often get on random instance an
AttributeError @@plone and all other browser pages. I have tracked
it down to a ConflictError when installing Five on startup. See
traceback bellow. To solve this I tried to set
enable-product-installation = off to all except one instance but I
still got errors.
For now we restart the broken instances until they work, I have
tried to set sleeping times up to couple seconds between the
instances but it didn't make any difference.

Five fails when it tries to execute the registerPackage in zcml
files. Not the same product every time.
First I thought it didn't respect the enable-product-instalation but
that is checked in App.Product.initializeProduct method. 
So I played in fiveconfigure.py with transaction.savepoint() but no

success but if I manually check App.Product.doInstall like in the
diff below 


Now my question is if this is correct solution for the problem or
will it have other side effects that I am not aware of? How do I
write tests for an ConflicError during startup?

/Sasha

Index: fiveconfigure.py
   
 
===
   
 
--- fiveconfigure.py(revision 86781)
   

+++ fiveconfigure.py(working copy)  
   

@@ -23,7 +23,7 @@  
   
 
 import warnings
   


   

 import App.config  
   

-from App.Product import initializeProduct  
   

+from App.Product import initializeProduct, doInstall  
   
 
 from App.ProductContext import ProductContext  
   

 import Products
   

 from zLOG import LOG, ERROR
   

@@ -265,6 +265,8 @@
   
 
 if not hasattr(module_, '__path__'):  
   
 
 raise ValueError("Must be a package and the " \

[Zope-dev] Re: zope.testing console script

[Philipp von Weitershausen]

Tarek Ziadé wrote:

If nothing exists, I would like to suggest adding a setuptools
console entry point in zope.testing setup.py file, to get a python
script in the $PYTHON/bin folder, exactly like what
zc.recipe.testrunner does.


+1


It could be called "zope.testrunner" maybe ? (nose= nostests, py.test = py.test)


I suppose having it called 'test' (which is our convention) is a bit 
arrogant. But calling it 'zope.testrunner' creates the allusion that the 
package is called zope.testrunner as well. How about 'run-zope.testing' 
or something along those lines?

___
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] Re: i18nmessageid has a broken link

[Philipp von Weitershausen]

Maurits van Rees wrote:

Without having tried pure Zope 3, only Grok --- I have been working on
grokproject during the Grokkerdam sprint --- the following in
buildout.cfg should work just as well:

find-links = http://download.zope.org/distribution/
extends = http://download.zope.org/zope3.4/versions.cfg
versions = versions

The find-links is needed because it has some package versions that
were never released on the cheese shop.  The versions.cfg defines
which versions are actually used.


What packages are not released on PyPI yet? I was under the impression 
that find-links is no longer needed.


___
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] Re: i18nmessageid has a broken link

[Philipp von Weitershausen]

Sebastian Wehrmann wrote:
the zope.i18nmessageid package has a broken link on 
http://download.zope.org/zope3.4/zope.i18nmessageid/ . The 
'zope.i18nmessageid-3.4.3-py2.4-linux-i686.egg' does not exist any more 
on pypi.


Right. It was deliberately removed because binary eggs should never ever 
be uploaded (unless they're for Windows).



Could someone please fix it?


I'm cc'ing Stephan Richter who maintains the KGS. I think this is a 
matter of re-generating the KGS index that sits at 
http://download.zope.org/zope3.4.

___
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] Re: NotFound

[Philipp von Weitershausen]

Roger Ineichen wrote:
Is there a reason why zope.publisher.interfaces.NotFound 
is not locatable?


class NotFound(LookupError, TraversalException):
implements(INotFound)

def __init__(self, ob, name, request=None):
self.ob = ob
self.name = name

Why should a NotFound error instance not be locatable
by default since it provides a location?


What kind of a location does it provide?
___
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] Re: Why I dislike narrative doctests

[Philipp von Weitershausen]

Lennart Regebro wrote:

On Thu, Apr 24, 2008 at 10:07 PM, Jim Fulton <[EMAIL PROTECTED]> wrote:

 - If a file is documentation and a test, make sure it is good
documentation. In that case, documentation comes first. Don't add so many
tests that it ruins the documentation.

 - Test edge cases in separate tests.  These are typically short-ish strings
in test modules.

 - A variation is to have a narrative that doesn't try hard to be
documentation.  The narrative can be convenient, up to a point, even in a
test.  These should be clearly marked as not being documentation.


I'ö happy to here this from an authorative source. I've been saying it
for years, and I have usually been contradicted by people saying "no
all tests should be doctests", Lets kill that sillyness once and for
all now. :-)


I've written such rules down: 
http://svn.zope.org/Sandbox/philikon/foundation.


If it's missing something, feel free to suggest a patch.
___
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] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]

[Philipp von Weitershausen]

On 19 Apr 2008, at 22:39 , Chris McDonough wrote:

Philipp von Weitershausen wrote:

Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on  
this, and get Chris McDonough's input.


IMO, a Zope2 egg release should depend on the following packages:

- 'ZODB3' (already packaged)

- 'transaction' (depended on by newer ZODBs)

- 'ZConfig' (also depended on by newer ZODBs)

- 'StructuredText' (should be broken out into its own egg)

- 'docutils' (should use existing egg)

- 'mechanize' (should use existing egg)

- 'pytz' (should use existing egg)

- all zope.* packages (properly pinned) that zope2 depends on

Yup. These are all done already.
The actual top-level egg that depends on these things would  
contain all the other packages depended on by Zope 2 (e.g.  
DateTime, Missing, Products/*, Acquisition, ExtensionClass,  
ZPublisher, ZServer, etc).
Yup, we can do it like that. I still maintain that the zLOG,  
Interface and DateTime packages could be packaged separately  
without much effort. The benefit with those is that they'll either  
be obsolete very soon (zLOG, Interface) or may need off-beat  
updates (DateTime).


I'd be slightly happier if everything "we" (Zope 2 folks, as opposed  
to Zope 3 folks, ZODB folks, or other independent authors) maintain  
shipped inside a single egg.


In particular, I think this might be what to aim for in the very  
first Zope 2 egg-based release, because we can always move stuff out  
in a later release, but it's harder to reel something back in if we  
find that moving it out has been a mistake.  The "one big egg"  
strategy might also let us explain it a little more easier to old- 
hand Zope2 devs who aren't used to eggs: "everything that used to be  
in the tarball except ZODB, Zope 3 libraries, and external libs is  
in the zope2 egg".  Then in a subsequent Zope 2 egg release, we  
could say "oh, now that you're used to eggs, we've moved DateTime  
out into a separate egg", so on and so forth.


Ok, fine by me.

But I'll try not to get hung up on it if other really want to bust  
things apart.  I guess in particular, I'm not keen on trying to  
externalize ExtensionClass or Acquisition unless somebody else has a  
strong desire to do this because they're using them outside Zope  
somehow.


Which they're not :).


We might call it 'zope2libs'.

What's wrong with just 'Zope2'?


It would be nice to disambiguate the libraries needed to run Zope 2  
from the wrapper stuff required to configure an instance.  The very  
outmost "meta-egg" (or buildout, or whatever) should probably be  
named Zope2.  This might or might not be it.  If this *is* that  
outermost egg, "Zope2" sounds good to me.


Well, taking your "everything that used to be in the tarball..."  
argument, then this would indeed be the outmost egg, incl. the  
instance scripts.


A nit:  I might call the outermost egg "zope2" because I have a  
preference for lowercase egg names and we also already have a  
*package* named "Zope2", and it'd be nice to know where you are at  
the bash prompt without needing to print the whole path.


I have a slight preference for "Zope2" because that's what egg names  
usually look like. Also, if you told people Zope 2 was now available  
in egg form and asked them to guess what the egg was called, I think  
most would come up with "Zope2".


___
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.org Redux] Re: [Zope-dev] Let's fix the damned website

[Philipp von Weitershausen]

On 21 Apr 2008, at 11:53 , Martin Aspeli wrote:
 - "Projects" gives an explanation of how the different Zope  
projects fit
together (Zope 2, Zope 3, Grok, CMF, ZODB). Each is then given a  
subfolder
that contains a standard structure: A front page that explains the  
project
in more detail, "Get" (downloads), "Taste" (as above, but for a  
particular

project) and "Learn". The "Learn" section should contain relevant,
up-to-date documentation.


No!

Each project should have it's own site. Like Grok has today. The
Projects page which explains what they are and how they fit together
is fine, but the different subparts will necessarily have to be
maintained by slightly different people with slightly different
requirements.

We can set up rules so that both zope.org/Projects/grok and
grok.zope.org point to the same physical place, but it is extremely
important that we do not, once again, try to make a monolithic
zope.org.

Microsites, microsites, microsites!


Does it really matter whether a microsite lives in
zope.org/projects/zodb or zodb.zope.org?

If you look at the projects now, they each have a common set of
sections - download, examples, documentation - and will be allowed to
evolve independently. They also have the option of having some
specific branding (logo, tag-line etc) as required.

If anyone steps up and wants to maintain a separate site for one of
the projects, then all the better. However, it is hard enough to get
contributors as-is, so I'm loth to do anything that increases the
maintenance or setup burden in any way until we have at least the
basics in place.


I agree with Martin. We need to stop the balkanization of Zope-the- 
brand. Yes, we have many individual projects, but we need a coherent  
image to the outside world. Microsites was a good idea to get  
foundation site and the Grok site up and running *before* tackling  
zope.org, but in the long run, we need coherence.


Also, to be honest, I don't find the design of the new Grok website  
very attractive. And the foundation site is simple enough to be folded  
back into the main site.


___
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] Re: Proposal: Merge philikon-aq branch into Zope trunk

[Philipp von Weitershausen]

Martijn Faassen wrote:

Tres Seaver wrote:
[snip]
The second problem that might arise, is that the implicit assumption 
that every object inside Zope 2 inherits from Acquisition base 
classes no longer holds. Code that relies on the various aq_* 
attributes to be there need to be adjusted to use the Acquisition 
methods instead.


The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes.  ('aq_base' should not be allowewd at all, as
it strips away security context).

There are probably thousands (or even tens of thousands) of templates
and scripts "in the wild" which use these attributes.  I don't think we
can break them in a single release:  we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.


I'm trying to understand what is proposed that would break them. All 
existing content objects will continue to use acquisition. Only things 
like Five views will stop using acquisition and switch to a __parent__ 
pointer. I doubt there are that many scripts that rely on getting a 
.aq_parent, say, on a Five view. There will be view code that relies on 
this, so I imagine we expect that should be rewritten to use the 
functions instead, but not scripts.


You're right, and Tres acknowledged that in a follow-up post already :). 
What's more, views actually *do* have those aq_* attributes for BBB, so 
even those scripts that do view.aq_parent will continue to work no 
problem. See my answer to Tres's post.


If we were to change OFS so that it'd start using __parent__ then I can 
see where you're coming from, but I don't think anyone's proposing that?


Nope. And it would be quite an involved thing to do, because currently 
Zope 2 objects have no persistent reference to their parent whatsoever 
(in fact, parent i.e. cyclic references used to be unsupported by early 
ZODB versions). So basically, if you wanted to introduce __parent__ 
pointers to existing Zope 2 objects, you'd have to traverse the whole 
object tree and set them based on their acquisition parent. I *suppose* 
this could be done ad-hoc (when you first traverse over an object that 
doesn't yet have its __parent__ pointer set), but I'd rather not think 
this through right now.


So, like I said, it's not on my list, and I bet it won't be for a long 
time. Mostly because a) it's probably unnecessary and b) much code in 
fact relies on content being of the type Acquisition.Implicit... 
 anyone? :)

___
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] Re: Zope 2 eggification [was: Merge philikon-aq branch into Zope trunk]

[Philipp von Weitershausen]

Chris McDonough wrote:
I wonder if Philipp would be amenable to writing a proposal on this, 
and get Chris McDonough's input.


IMO, a Zope2 egg release should depend on the following packages:

- 'ZODB3' (already packaged)

- 'transaction' (depended on by newer ZODBs)

- 'ZConfig' (also depended on by newer ZODBs)

- 'StructuredText' (should be broken out into its own egg)

- 'docutils' (should use existing egg)

- 'mechanize' (should use existing egg)

- 'pytz' (should use existing egg)

- all zope.* packages (properly pinned) that zope2 depends on


Yup. These are all done already.

The actual top-level egg that depends on these things would contain all 
the other packages depended on by Zope 2 (e.g. DateTime, Missing, 
Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc).


Yup, we can do it like that. I still maintain that the zLOG, Interface 
and DateTime packages could be packaged separately without much effort. 
The benefit with those is that they'll either be obsolete very soon 
(zLOG, Interface) or may need off-beat updates (DateTime).



We might call it 'zope2libs'.


What's wrong with just 'Zope2'?

What needs to get worked out is the ability 
to share headers between ZODB and this package so things can compile 
properly.


I don't see this as a huge problem. You have a point that C headers 
introduce un-documented dependencies, but then again, how often do C 
headers change? It has worked so far with externals to the ZODB tree, 
it's not like anything's going to change there any time soon. (For 
instance, when I hacked Acquisition to support __parent__ pointers, I 
didn't have to change the headers either).


___
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] Re: Proposal: Merge philikon-aq branch into Zope trunk

[Philipp von Weitershausen]

Tres Seaver wrote:
The second problem that might arise, is that the implicit assumption 
that every object inside Zope 2 inherits from Acquisition base classes 
no longer holds. Code that relies on the various aq_* attributes to be 
there need to be adjusted to use the Acquisition methods instead.


The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes.  ('aq_base' should not be allowewd at all, as
it strips away security context).

There are probably thousands (or even tens of thousands) of templates
and scripts "in the wild" which use these attributes.  I don't think we
can break them in a single release:  we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.


Here's the deal:

* Instances of (subclasses of) Acquisition.Implicit and .Explicit still 
have those aq_* attributes. So basically all content objects still have 
them, no change there.


* Five's BrowserView class doesn't inherit from Acquisition.Explicit 
anymore, but we've provided the aq_* attributes for backward 
compatibility. So if a template does view/aq_parent, it will still work 
(we have tests for this). We haven't set an expiry date for this BBB, 
nor are we logging a warning. We probably should, though, if we 
eventually want to phase out Five's BrowserView class.



So, off the line there's no backward-compatibility problem. Now if 
people decide to implement their content objects without Acquisition 
(which they now can), then it's their problem if their templates still 
do obj/aq_*. This can be alleviated with a mix-in that Five has, which 
makes classes regain the aq_* attributes. Not sure if we want to make 
this public in any way, currently it's basically used for BrowserView 
and ViewletBase.

___
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] Re: Proposal: Merge philikon-aq branch into Zope trunk

[Philipp von Weitershausen]

Hanno Schlichting wrote:

Timeline:

I would like to do the merge as soon as possible, so people can easily 
test it against all their applications and report back problems.


Merging it into Zope trunk will get it into the Zope 2.12 release which 
is at this point not scheduled yet, but is unlikely to get a release 
before early 2009. This should give us plenty of time to test.


This sounds good. Here's another idea, though: In accordance with 
"release early and often", how about scheduling the 2.12 release shortly 
after the 2.11 one? So the only "new" thing in 2.12 would be the 
philikon-aq branch (it would still ship with the same Zope 3 libraries 
as 2.11, etc.).



Opinions, votes?


+1 :)


P.S. Thanks to philiKON for doing most of the work on this branch :)


And thanks to Hanno for testing it against Plone and making lots of 
improvements!

___
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] Re: AQ-Parent branch test failues was: Re: Five and browser-oriented components

[Philipp von Weitershausen]

Wichert Akkerman wrote:

Previously Philipp von Weitershausen wrote:
ViewPageTemplateFile etc. are only meant to be used as class attributes, 
never as instance attributes. This statement is also true for the 
current, acquisition-based one from Five.


Is that documented anywhere? I can't seem to find any interface or
docstring that documents that.


I suppose not, because ViewPageTemplateFile (or ZopeTwoPageTemplateFile, 
as it used to be called) was and still is poorly documented. Initially, 
it was only used internally by the ZCML directives until people started 
 writing the view template explicitly into the view class, much like in 
Zope 3.


So no, there isn't documentation about the Five bit. But there *is* 
documentation about the Zope 3 bit (my book, for instance), so my 
argument is mostly based on the principle of correspondence between Five 
and Zope 3.



In my opinion, the fact that it accidentally worked as an instance
variable isn't a very strong argument for continuing to support it. To
me, this is a prime example of misusing a Five component which now
leads to problems when we go pure Zope3.


I'ld agree if there was a docstring or interface that made that
explicit. I've updated the relevant code in plone.app.portlets though
since the change is harmless.


Cool, that's great. If this is just a matter of a docstring, I'm sure 
that can be arranged :)

___
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] Re: AQ-Parent branch test failues was: Re: Five and browser-oriented components

[Philipp von Weitershausen]

Thanks for looking into this, Hanno! Here's my feedback:

Hanno Schlichting wrote:

Hanno Schlichting wrote:
I kept my promise and added the simple tests for the first two issues 
I found while doing testing against Plone.


I have meanwhile fixed the first trivial issue (conflicting argument 
called 'instance')


I took a look at it. Thanks! It's too bad that we have to duplicate so 
much code from Zope 3 now. Therefore I would suggest that we fix up 
zope.app.pagetemplate properly so that it won't conflict with 
'instance'. Then we can get rid of the duplication in Five. Thanks to 
the individual projects nowadays, it should be trivial to update 
zope.app.pagetemplate.


[...]
Now as you can see the only difference is that one of them uses a class 
variable for assigning the template and the other one is using an 
instance variable.


ViewPageTemplateFile etc. are only meant to be used as class attributes, 
never as instance attributes. This statement is also true for the 
current, acquisition-based one from Five. In my opinion, the fact that 
it accidentally worked as an instance variable isn't a very strong 
argument for continuing to support it. To me, this is a prime example of 
misusing a Five component which now leads to problems when we go pure Zope3.


From what I understand some magic place in between doesn't find the 
template instance variable during ZCML processing as it operates on 
classes only and therefor doesn't turn the template into a 
BoundPageTemplateFile.


It doesn't happen during ZCML processing. It's a simple class 
descriptor, so the magic happens in ViewPageTemplateFile's __get__ which 
is invoked each time you do view.template (the '.' invokes __get__). I 
recommend reading about new-style class descriptors and properties.


Using an instance variable called template and calling it later on 
without passing in the view as the first argument doesn't work at all in 
Zope3. In Zope2 it did so far, as the ViewPageTemplateFile would use 
Acquisition to find its view.


Right. This led to all sorts of weird and icky problems, so thank God 
it's gone now.



I don't have any good idea on how to handle this problem.


Do we really have to support instance-level templates? I would still 
argue that if anybody's using ViewPageTemplateFile like this, they're 
using it wrong. I personally have no intent on supporting this.


If we really have to support it, then there's a simple solution: don't 
use ViewPageTemplateFile for instance-level attributes, use a variant 
that we provide instead. We could introduce this variant in both 
pre-AQ-parent and post-AQ-parent Zope versions to ease compatibility.


We can 
probably walk up the stack frame to find the view in most cases, as the 
template is called in almost all cases directly from the view.


-1. Walking up stack frames for guessing stuff like this will usually 
destroy you.


But the third test failure, which I haven't written a test for yet, 
breaks even then. Essentially it puts in an adapter in between the view 
and the template where the adapter doesn't have any reference to the 
view anymore, so getting to the view from the template is impossible 
even by walking up the stack frame. This use-case is highly specialized 
(the code is in plone.app.form._named) but currently it works in Zope2.


You're probably referring to the NamedTemplate thing that zope.formlib 
has (and plone.app.form reimplements the stuff for Zope 2). In 
zope.formlib, the same __get__ technique that ViewPageTemplateFile uses 
is used to get a hold of the view instance when you do view.template. 
plone.app.form's replacement for this technique is to use acquisition to 
get at the view. This obviously has to go since acquisition is no longer 
supported for views. In fact, if I'm not mistaken, this bit of 
plone.app.form can entirely be ripped out.


Given that plone.app.form does monkey patches (which I'm unwilling to 
support in any means, the original authors made potential 
incompatibilities their problem when they introduced them), I'm almost 
certain that there will never be one version of plone.app.form that will 
work with both the pre-AQ-parent and the post-AQ-parent Zope. You could 
still try, of course. At the very least, you could make a try/except 
clause. Either way, as I said, I'm not offering my help for this package 
since it contains monkey patches.

___
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] Re: Five and browser-oriented components

[Philipp von Weitershausen]

Malthe Borch wrote:
On Z2, certain imports need to come from Products.Five, to play nicely 
with ZPublisher and friends.


Not really. You can inherit from zope.publisher.browser.BrowserView and 
Five's  directive will magically slap 
Acquisition.Explicit into a newly-created subclass that will be 
registered as a view.


I'd like to ask for the motivation for not patching it onto the existing 
classes and/or modules.


Because monkey-patches are evil. And I won't accept any "buts" here. 
They're just evil, hard-to-impossible to test and most important of all, 
absolutely unfathomable for the novice developer.


The effect of having Z2-developers import from 
Products.Five is that they must opt out on packages that make use of 
templates, browser views, formlib, ... --- and it adds needless complexity.


AFAIK, Plone already monkey patches formlib so you won't even have to 
change those imports.


This split might also have prompted the Plone community to walk their 
own way to the extend that there isn't much code reuse outside of the 
core Zope packages (along with egg dependencies, but with our fake eggs, 
we're almost up to par here).


I still believe the answer is my Acquisition + __parent__ patch. As 
mentionen in this thread already, it's several years old now (yikes!) 
but should merge quite cleanly, actually. Zope's own tests pass nicely, 
as do the CMF's, only Plone's tests fail in one or two places in an 
obscure way (and I'm talking about the whole ploneout testsuite here).


*IF* you'd like to be pragmatic, I'd suggest we clean up those failing 
Plone tests, merge the branch and be on our way. Yes, we *might* be 
plastering over a potential problem in the patch, but the other  
tests didn't seem to be affected and intensive alpha and beta testing of 
that new Zope version would likely confirm or refute the existence of a 
serious problem. To be honest, my suspicion is that Plone is using some 
of the Five stuff in a way that it shouldn't be, hence causing a test 
failure with the cleaned up Five. Hanno removed some of the Five-raping 
procedures in Plone already, but there might be others lurking around 
and causing test failures.


___
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] Re: Five and browser-oriented components

[Philipp von Weitershausen]

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:

Martijn Faassen wrote:

Technically, I think that this is going to be hard. You'd need to patch 
in the magic acquisition base class. Acquisition is the main reason that 
some of the code needed to be duplicated - without the existence of 
acquisition wrappers, security checks are not made for view access and 
things just won't work.
I think if we could finish the philikon-aq_parent branch (or whatever 
it's called) that makes it possible to do acquisition using __parent__ 
pointers, we'd be a lot closer.


AFAIU, that branch doesn't provide *acquisition* via the __parent__
pointer:


No, it does. It makes __parent__ pointers completely equivalent to 
explicit acquisition wrappers.



rather it allows the containment-based security check, which
currently uses the 'inner' acquisition wrapper, to use the chain of
'__parent__' pointers as an alternative when no acquisition wrapper is
present.


The security machinery (AccessControl) does an aq_aquire(obj, 
'__roles__') check. With __parent__ pointers, this will resolve properly.


The branch is indeed "ready" from Zope's own point of view. Last thing I 
remember is that one (!) Plone tests fails in an obscure way. Then 
again, one failing test sometimes is enough :)

___
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] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?

[Philipp von Weitershausen]

Philipp von Weitershausen wrote:

Andreas Jung wrote:

during the latest 'zope.publisher' thread on zope-dev I came up with
the proposal to eggify the Zope core for the Zope 2.12 release. I 
would like to start a discussion about the pros and cons, risks and 
advantages of any eggification effort.


Chris favors a 'big' Zope egg with some dependencies (like ZODB) 
stripped out.


I have pretty much done this already. [1] defines an egg called 'Zope2'. 
All the Zope 3 eggs are dependencies, as are a few "non-core" packages 
such as ExtensionClass, Acquisition, etc. (which are already eggified 
and available on PyPI).


I should add here that the 'Zope2' egg is far from finished. The things 
I split off (Acquisition, DateTime, ExtensionClass, etc.) are working 
fine by themselves, but the 'Zope2' egg needs some more attention to get 
its tests passing and to get it working in a production environment.


I think *one* good goal of this sprint could be to switch repoze.zope2 
over from using the 'zopelibs' egg to using the 'Zope2' egg. The 'Zope2' 
egg should still work by itself in an instance-like fashion, obviously.

___
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] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?

[Philipp von Weitershausen]

Wichert Akkerman wrote:

Previously Martin Aspeli wrote:
I'm not sure this is all that useful. For Plone 4, we're just going to 
have a number of plone.*, plone.app.* and Products.* (and a few others, 
like kss.*) eggs that we can put in a KGS or version pin in a single 
"Plone" egg.


For Plone 4 we may also collapse all the plone.app.* packages in a
single package. 


+sys.maxint
___
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] Re: [Zope 2.12] Eggification of Zope 2 - pros and cons?

[Philipp von Weitershausen]

Andreas Jung wrote:

during the latest 'zope.publisher' thread on zope-dev I came up with
the proposal to eggify the Zope core for the Zope 2.12 release. I would 
like to start a discussion about the pros and cons, risks and advantages 
of any eggification effort.


Chris favors a 'big' Zope egg with some dependencies (like ZODB) 
stripped out.


I have pretty much done this already. [1] defines an egg called 'Zope2'. 
All the Zope 3 eggs are dependencies, as are a few "non-core" packages 
such as ExtensionClass, Acquisition, etc. (which are already eggified 
and available on PyPI).


I also started a branch of the Plone egg back then to see if it can be 
modified to install Zope 2 completely as a dependency. See [2].



I would prefer a more broader approach. One of the reasons are
company-internals modifications to the Zope core. Right now we 
maintain a more or less heavy modified version of Zope 2.8 in our

repos (making Zope upgrades pretty hard). A better modularization
would help  us here. Another example:
the Plone people maintained a Zope 2.10 branch with experimental ZODB
blob support. With an eggified version of ZODB you could easily
switch the eggs (easily spoken).


I feel indifferent to this in general, so feel free to split away more 
stuff from my 'Zope2' egg.


So before promoting the eggification as an ultimate goal, let's discuss 
what we really need and want. A complete eggification just for the sake 
of eggs is possibly not the goal :-)



[1] http://svn.zope.org/Zope2.buildout

[2] http://svn.plone.org/svn/plone/dist/Plone/branches/philikon-buildoutify
___
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] Re: buildout 'versions' and 'develop' conflict

[Philipp von Weitershausen]

Christophe Combelles wrote:

Martijn Faassen a écrit :

(...)



I think the term 'develop' is badly chosen. You are right if you argue 
while having the meaning of 'develop' in mind. You are explaining what 
you think a 'develop' option should be. A 'develop' option means: "I 
want to 'develop' on this package, so I want it active, otherwise I 
don't put 'develop'".


But probably the feature has been created before the name 'develop' was 
chosen, and it should have an other name ('egg_path'? 'local_egg'?).
However something has to be done because some people find it not 
logical, some other people will probably have headaches with it.


I think Jim chose to name this option simply 'develop' because for each 
directory specified in it, it will call 'python setup.py develop'.

___
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] more on stacked component registries

[Philipp von Weitershausen]

On 5 Feb 2008, at 19:23 , Chris Withers wrote:

Stephan Richter wrote:

On Tuesday 15 January 2008, Chris Withers wrote:

For what I'm after, I need to have a more dynamic buildup of
registrations based on which objects have been traversed through.
Right. I think the component architecture is not really made for  
this.


Sure it is, I'm talking about what basically happens with nested  
site managers. The problem is that the current nesting  
implementation seems predicated on zodb-like persistence. I'm  
looking at storing all "data", including site managers, in a  
relational database. The actual folder structure should remain as  
static as it does with zodb...


Well, each place in the ZODB will still know that it is a site, i.e.  
that it has a site manager associated, right? Because then you can  
easily track down the same registry over and over again. You could  
probably even register them as global utilities for easy access (like  
it's done with other registries, e.g. the ones from z3c.baseregistry).


I think it would be easier to turn on/off registrations by using  
dynamically directly provided interfaces (via a proxy) or use  
security.


Not sure what you mean by either of these...


You can change which adapters are found for a particular object by  
applying marker interfaces.



- stack the registries up during travesal in some way. I guess this
  would be a variant of what's done now with current nested  
registries.

  Is this feasible? Will there be performance problems?
I think the performance would decrease, because caches cannot be  
built up. Also, you then must be able to access this custom  
registry. Remember, this must be all in memory, because of thread- 
safety!


Yeah, but this is what happens more static-ly with the existing site  
managers, right?


I'm not sure how the ZODB-based registries do caching. I strongly  
suspect that their caches may be garbage-collected at any time after  
the request is over. Also, let's not worry about premature  
optimizations right now...


- use one global registry and add/remove registrations during  
traversal
as necessary. How fast is registration/unregistration of adapters  
and

the like? How many adapter adds/removes at a traversal node would it
take to really slow things down?

You cannot do this; it is not thread-safe.


Well okay, one registry per thread... would that work?


So you would basically copy the whole global registry to a thread- 
local variable at the beginning of the request, then modify it and  
then throw it away afterwards? Doesn't sound very clever to me...


___
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] Re: SVN: Zope/trunk/lib/python/zope/app/ added various zope.app packages for backward compatibility

[Philipp von Weitershausen]

Andreas Jung wrote:

Log message for revision 83064:
  added various zope.app packages for backward compatibility


Wrong branch :/. It's fine for those to be missing from the *trunk*, 
since they were scheduled for removal for Zope 2.12 anyway. They just 
need to be there on the 2.11 branch.


But you're on the right track ;). Thanks.
___
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] Re: proxies

[Philipp von Weitershausen]

P.S.: This is explained in detail in my book, chapter on containers.


___
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] Re: proxies

[Philipp von Weitershausen]

Chris Withers wrote:

Hi All,

I saw the zope.proxies module and wondered if it might be able to help 
me with two problems I need to solve:


- can these proxies be used to keep track of a traversal path in much 
the same way (although no seperate containment and context chains 
needed) as the old Zope 2 acquisition wrappers did?


We generally assign a __parent__ attribute to objects that have a 
hierarchical parent object. Objects have to explicitly allow this by 
providing ILocation (or the derived IContained). If they're not ok with 
having __parent__ assigned, we wrap them in a persistent containment 
proxy [1]. It will make the original object behave normally, except for 
the ILocation/IContained API (__parent__, __name__ attributes). It will 
intercept those values and store them inside the pickled proxy. THat way 
the object won't ever see the __parent__ attribute assigned to itself.


- once a proxy has been created, the the object it's proxying for be 
replaced?


I don't understand this question.

You'll have to explicitly do the wrapping and then continue to work with 
the wrapped object. Container implementations use the following kind of 
code in __setitem__ [2]:


if not IContained.providedBy(object):
if ILocation.providedBy(object):
zope.interface.alsoProvides(object, IContained)
else:
object = ContainedProxy(object)

and then they add 'object' to their datastructure (e.g. a BTree) and 
assign object.__parent__ and object.__name__.



[1] zope.app.container.contained.ContainedProxy
[2] zope.app.container.contained.containedEvent
___
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] Re: [Zope 2.11] KGS incomplete (Was: Stepping forward and going beta)

[Philipp von Weitershausen]

On 25 Dec 2007, at 10:58 , Andreas Jung wrote:

"/opt/python-2.4.4/bin/python" "/Users/ajung_data/sandboxes/Zope/
ajung-2-11-prep-branch/test.py" -v
Running tests at level 1
Running unit tests:
Running:
..
rror in test testSetupConfiguredLoggers
(Zope2.Startup.tests.testStarter.ZopeStarterTestCase)
Traceback (most recent call last):
File "/opt/python-2.4.4/lib/python2.4/unittest.py", line 270, in run
 self.tearDown()
File "/Users/ajung_data/sandboxes/Zope/ajung-2-11-prep-branch/lib/
python/Zope2/Startup/tests/testStarter.py", line 69, in tearDown
 test_logger.LoggingTestBase.tearDown(self)
File "/Users/ajung_data/sandboxes/Zope/ajung-2-11-prep-branch/lib/
python/ZConfig/components/logger/tests/test_logger.py", line 72, in
tearDown
 assert loghandler._reopenable_handlers == []
AssertionError
...


I can say nothing about these failures. It seems like they're
ZConfig-related.


Jup. But I could not figure the issue so far..anyway appears
as a minor issue for me so far.


Should still be dealt with before going final nevertheless...

Those two are related to an unplanned split-up of  
zope.app.securitypolicy
and zope.app.session. They occurred in the 3.4.x line even though  
they
should've in the 3.5.x line. So, what you'll need to do is add  
externals

for zope.session and zope.securitypolicy (notice the missing "app"!)
according to the KGS. That should get that settled.


Jup. In addition zope.minmax has to be added.

Because the ZConfig issue (see above) is the only problem so far, I've
moved my branch and made it the official 2.11 branch:




Cool! We should probably put the same set of externals on the trunk as  
well...



I'll wrap it as a gift and release it over the weekend.


/me lights the Christmas tree and cracks a few walnuts...

Philipp

___
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] Re: [Zope 2.11] KGS incomplete (Was: Stepping forward and going beta)

[Philipp von Weitershausen]

On 24 Dec 2007, at 16:32 , Andreas Jung wrote:

WARN: KGS incomplete - zope.app.content_types not found
WARN: KGS incomplete - zope.app.event not found
WARN: KGS incomplete - zope.app.filerepresentation not found
WARN: KGS incomplete - zope.app.location not found
WARN: KGS incomplete - zope.app.mail not found
WARN: KGS incomplete - zope.app.rdb not found
WARN: KGS incomplete - zope.app.servicenames not found
WARN: KGS incomplete - zope.app.site not found
WARN: KGS incomplete - zope.app.size not found
WARN: KGS incomplete - zope.app.tests not found


I kicked them.


Well, they've been deprecated for a while but it says they were  
scheduled for removal in Zope 3.5 which corresponds Zope 2.12. So we  
can't get rid of them just yet. Zope 2.11 shoudl still contain them.


IMO it's fine to simply leave the externals from the 2.10 branch for  
them in place.



I created a test branch and adjusted the externals so far.

zope.thread seems to be a broken (there is no _zope_thread.c
file)...however had no time for further investigations.


As Tres pointed out, the C extension is gone, so you can just remove  
that entry from setup.py.



And the testrunner produces 9 errors...anyone with a fast idea about
the reasons for the failures (before doing further investigations)?

"/opt/python-2.4.4/bin/python" "/Users/ajung_data/sandboxes/Zope/ 
ajung-2-11-prep-branch/test.py" -v

Running tests at level 1
Running unit tests:
Running:
..
rror in test testSetupConfiguredLoggers  
(Zope2.Startup.tests.testStarter.ZopeStarterTestCase)

Traceback (most recent call last):
File "/opt/python-2.4.4/lib/python2.4/unittest.py", line 270, in run
  self.tearDown()
File "/Users/ajung_data/sandboxes/Zope/ajung-2-11-prep-branch/lib/ 
python/Zope2/Startup/tests/testStarter.py", line 69, in tearDown

  test_logger.LoggingTestBase.tearDown(self)
File "/Users/ajung_data/sandboxes/Zope/ajung-2-11-prep-branch/lib/ 
python/ZConfig/components/logger/tests/test_logger.py", line 72, in  
tearDown

  assert loghandler._reopenable_handlers == []
AssertionError
...


I can say nothing about these failures. It seems like they're ZConfig- 
related.



Running zope.testbrowser.tests.TestBrowserLayer tests:
Tear down zope.formlib.tests.FormlibLayer in 0.005 seconds.
Set up zope.testbrowser.tests.TestBrowserLayer Traceback (most  
recent call last):

...
  ImportError: No module named session.interfaces



Running zope.traversing.tests.layer.TraversingLayer tests:
Set up zope.traversing.tests.layer.TraversingLayer Traceback (most  
recent call last):

...
  ConfigurationError: ('Invalid value for', 'package', 'ImportError:  
Module zope has no global securitypolicy')


Those two are related to an unplanned split-up of  
zope.app.securitypolicy and zope.app.session. They occurred in the  
3.4.x line even though they should've in the 3.5.x line. So, what  
you'll need to do is add externals for zope.session and  
zope.securitypolicy (notice the missing "app"!) according to the KGS.  
That should get that settled.


Thanks for tackling this, Andreas.

Merry Christmas,
Philipp

___
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] Re: [Zope 2.11] Stepping forward and going beta

[Philipp von Weitershausen]

Andreas Jung wrote:
--On 18. Dezember 2007 21:53:55 +0100 Hanno Schlichting 
<[EMAIL PROTECTED]> wrote:



Andreas Jung wrote:

the Zope 2.11 beta phase has been delayed for while. The reason for
holding but the release was Philipps and Hannos work on the



branch. Unfortunately both can't work (lack of personal time) on the
branch and finish it in the feature. So I propose to release Zope 2.11
beta 1
by the end of the year w/o this branch. Zope 2.11 would contain the Zope
3.4 and ZODB 3.8 with blob support as major new features.

Objections? Thoughts?


+1 btw. Is there an ETA for beta1?


During x-mas and new year..likely around December 29th. If you need some 
more days, let me know but I would like to push the beta 1 release asap.


Note that doing a beta isn't just releasing the branch as it is. You 
should update all externals to the current 3.4.x releases of the 
individual eggs as well. The KGS [1] maintained by Stephan Richter 
provides you with a list of the most recent releases (except that the 
latest ZODB 3.8.0 candidate [2] isn't in it, apparently)


Also please be careful not to add or remove packages arbitrarily from 
the externals. If I remember correctly, a while back somebody just 
copied the externals from the Zope 3 tree to Zope 2 and added a bunch of 
not-releasable software to Zope 2 and removed other stuff in the process.



[1] http://download.zope.org/zope3.4/versions.cfg
[2] http://cheeseshop.python.org/pypi/ZODB3/3.8.0c1
___
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] Missing zope.sendmail changelogs

[Philipp von Weitershausen]

Hi there,

zope.sendmail is missing changelog entries for the last two releases. As 
far as I can tell from the checkins list (which isn't always accurate), 
these people have last worked on zope.sendmail:


* Marius Gedminas
* Benji York
* Albertas Agejevas

It would be cool if they and potentially other contributors who worked 
on zope.sendmail recently would update the changelog. Note that it's in 
README.txt, which was ok by the "old" rules. Nowadays a separate 
CHANGES.txt file seems to be preferred.


___
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] Re: zopeproject and external apidocs

[Philipp von Weitershausen]

Christophe Combelles wrote:

Hi,

When creating a buildout with zopeproject, the site.zcml puts the package
registration before the apidoc registration:


  

  
  


This means that the bookchapters of some added packages (such as z3c.*) 
will
never show up in the apidoc, because the /> will

be located **after** all the  zcml:condition="have apidoc"

I suggest to move the  on the top of the 
site.zcml

by default.


Thanks for the suggestion. Can you please file a bug report at 
https://launchpad.net/zopeproject. Thanks.

___
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] Re: getting RestrictedPython working on Python 2.5

[Philipp von Weitershausen]

On 5 Dec 2007, at 15:46 , Chris Withers wrote:
There's python setup.py develop, which will also install the  
checked out thing as a development egg,


What does that mean? Which python files would I edit to make changes  
in this case?


The ones you checked out. This isn't rocket science, you know :).

Also, you don't get a test runner this easily (though we should  
probably make python setup.py test work at some point, it currently  
doesn't work).


I might be interested in making that happen ;-)


Cool.

What still needs to be done? I'm imagining just plumbing the 'test'  
action through to running the zope.testing testrunner, or is there  
more to it than that?


No idea. You'll presumably have to deal with the tests_require thing  
as well.



The neat thign about the buildout way is that
- it's an absolute no-brainer


If you know what magic to incant ;-)


All you have to remember is python boostrap.py and bin/buildout. Not  
very hard. The advantage is that every single sandbox can be set up  
like this. I deploy all my sites like this now, be it Grok, Zope 3 or  
even Plone: checkout the project from SVN and enter the two command -  
done!


___
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] Re: getting RestrictedPython working on Python 2.5

[Philipp von Weitershausen]

Chris Withers wrote:

Philipp von Weitershausen wrote:

$ svn co $z/RestrictedPython/trunk RestrictedPython   (or a branch)
$ cd RestrictedPython
$ /your/development/python bootstrap.py
$ bin/buildout

$ bin/test

($z refers to svn+ssh://svn.zope.org/repos/main on my system)


Where does this put the code that I'd be changing?


Uh, you checked it out (first line: svn co).

Are any dependencies brought out as svn checkouts or just got as stable 
releases?


Dependencies will be downloaded from PyPI (or any other index you 
specify) as eggs.


Note that this procedure is the canonical one for all packages 
maintained in svn.zope.org nowadays.


OK, is there a non-buildout equivalent?


There's python setup.py develop, which will also install the checked out 
thing as a development egg, but it will try and install the dependencies 
 in the site-packages of the 'python' you used to call it with. This 
usually means isntalling things globally (unless you use virtualenv).


Also, you don't get a test runner this easily (though we should probably 
make python setup.py test work at some point, it currently doesn't work).


The neat thign about the buildout way is that

- it's an absolute no-brainer
- it's completely self-contained (nothing is installed outside that one 
directory, unless you explicitly allow that).

___
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] Re: getting RestrictedPython working on Python 2.5

[Philipp von Weitershausen]

Chris Withers wrote:

Hi All,

I'm looking to get RestrictedPython working in Python 2.5.
Has any work been done on this so far?

My first question is about the "right" way to get a checkout that I can 
develop in now. In years gone by, I would have created a branch of the 
whole of zope 3, checked it out and then started work.


Since eggification, I'm not sure what to do...
What I was planning on doing was creating a branch of RestrictedPython, 
checking that out and then manually checking out any dependencies from 
svn. Is there a "better" way to do this with easy_install or some such?



$ svn co $z/RestrictedPython/trunk RestrictedPython   (or a branch)
$ cd RestrictedPython
$ /your/development/python bootstrap.py
$ bin/buildout

$ bin/test

($z refers to svn+ssh://svn.zope.org/repos/main on my system)

Note that this procedure is the canonical one for all packages 
maintained in svn.zope.org nowadays.

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