Re: [Zope-dev] dependency cleanup progress report

[Jan-Wijbrand Kolman]

On Fri, Jan 30, 2009 at 3:47 PM, Martijn Faassen  wrote:
(snip)
> When you try these things it's a good idea to test the trunks of various
> packages against each other, so do consider using z3c.recipe.compattest
> with use_trunk mode to make sure your changes don't break anything.

That should be the "use_svn = true" option.

regards,
jw
-- 
Jan-Wijbrand Kolman
___
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: zope.container/trunk/ Adapt to the move of IDefaultViewName from zope.component.interfaces to zope.publisher.interfaces.

[Jan-Wijbrand Kolman]

Dan Korostelev wrote:
> Log message for revision 97660:
>   Adapt to the move of IDefaultViewName from zope.component.interfaces to 
> zope.publisher.interfaces.
> 
> Changed:
>   U   zope.container/trunk/CHANGES.txt
>   U   zope.container/trunk/src/zope/container/traversal.py
> 
> -=-
> Modified: zope.container/trunk/CHANGES.txt
> ===
> --- zope.container/trunk/CHANGES.txt  2009-03-08 09:52:54 UTC (rev 97659)
> +++ zope.container/trunk/CHANGES.txt  2009-03-08 09:58:46 UTC (rev 97660)
> @@ -5,6 +5,9 @@
>  3.7.2 (unreleased)
>  --
>  
> +- Adapt to the move of IDefaultViewName from zope.component.interfaces
> +  to zope.publisher.interfaces.
> +
>  - Add support for reserved names for containers. To specify reserved
>names for some container, you need to provide an adapter from the
>container to the ``zope.container.interfaces.IReservedNames`` interface.
> 
> Modified: zope.container/trunk/src/zope/container/traversal.py
> ===
> --- zope.container/trunk/src/zope/container/traversal.py  2009-03-08 
> 09:52:54 UTC (rev 97659)
> +++ zope.container/trunk/src/zope/container/traversal.py  2009-03-08 
> 09:58:46 UTC (rev 97660)
> @@ -19,11 +19,10 @@
>  
>  from zope.interface import implements, providedBy
>  from zope.component import queryMultiAdapter, getSiteManager
> -from zope.component.interfaces import IDefaultViewName
>  from zope.traversing.interfaces import TraversalError, ITraversable
>  from zope.publisher.interfaces.browser import IBrowserPublisher
>  from zope.publisher.interfaces.xmlrpc import IXMLRPCPublisher
> -from zope.publisher.interfaces import NotFound
> +from zope.publisher.interfaces import IDefaultViewName, NotFound
>  
>  from zope.container.interfaces import ISimpleReadContainer, IItemContainer
>  from zope.container.interfaces import IReadContainer

I think these changes should've been accompanied with a minimal version
requirement of 3.6.0 for zope.publisher in zope.container's setup.py right?

Will add that now.

regards,
jw

--
Jan-Wijbrand Kolman

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] zope.sendmail and testing

[Jan-Wijbrand Kolman]

Hello,

We're using zope.sendmail to send mail from our applications. These 
applications are built on top of a more generic application library. It 
is this application library that depends on zope.sendmail. This 
application library listens for certain events and then can decide to 
send out an email.

Obviously, when running the tests for the concrete application no mail 
is allowed to be actually sent.

Zope.sendmail explains in its README.txt that the developer using 
zope.sendmail should himself take care of not sending emails (by setting 
up a test layer for example, that would register a no-op IMailDelivery 
utility).

I had hoped that somehow zope.sendmail would automagically "detect" it 
is used during test runs and then would not send out any mails.

I dug around in zope.testing and found the cleanup module that seems to 
provide (if I understand correctly) a global registry of things to 
cleanup after tests. I wonder if this could be extended to also be able 
to register routines for globally setting up stuff - in this case it 
could stub the mail delivery so that never ever any mail is actually 
send out when running tests.

Questions:

1) how do others make sure that applications that directly or indirectly 
trigger sending mails do not actually send during testing?

2) am I on the right track thinking a "set up" equivalent of 
zope.testing.cleanup could be useful for these cases?

kind regards,
jw

--
Jan-Wijbrand Kolman

___
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.sendmail and testing

[Jan-Wijbrand Kolman]

Adam GROSZER wrote:
> Hello,
> 
> I'd rather use a mailer stub for testing.
> Like the one in zope.sendmail.tests.test_mailer.py
> 
> ...
> class SMTP(object):
> ...
> 
> Something like this can be setup for individual tests with
> 
>  name="mailer-name"
>   provides="zope.sendmail.interfaces.IMailer"
>   factory="your.own.mailerFactory"
>   />
> 
> def mailerFactory():
> mailer = SMTPMailer()
> mailer.smtp = SMTP
> return mailer 

Right, I see. However, what I meant to ask is if there is a way to have 
the registration of such a stub to be more or less automagically done 
during test runs by the zope.sendmail package instead of having to think 
about this over and over again in the packages directly or indirectly 
depending on it.

I *thought* to see a way of getting rid of global data in 
zope.testing.cleanup, and I wonder if we could think of a way to set up 
global data in a similar manner

regards,
jw


___
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.sendmail and testing

[Jan-Wijbrand Kolman]

Chris Withers wrote:
> Jan-Wijbrand Kolman wrote:
>> Zope.sendmail explains in its README.txt that the developer using 
>> zope.sendmail should himself take care of not sending emails (by setting 
>> up a test layer for example, that would register a no-op IMailDelivery 
>> utility).
> 
> Why not just use testfixtures [1] and Mock [2] to replace the SMTP class 
> in your testcase?
> 
> from mock import Mock
> from testfixtures import replace
> @replace('smtplib.SMTP',Mock())
> def test_mystuff(self):
> ...
> 
> That way you can check the right smtp calls are made, if you want to, 
> and there's no chance of mail being sent?
> 

My point is that I have to make sure the fixtures/mocking is done even 
in indirect consumers of zope.sendmail.

What I mean is, if I run the tests of my application Foo, that uses an 
application library MyLib where this MyLib library listens for events 
that can trigger email being send, I need to *not forget* to use these 
fixtures or mocks in the test setup of Foo. Even if the code of Foo does 
not itself call zope.sendmail.

I had hoped there would be a way for either zope.sendmail, or perhaps 
for MyLib, to make sure that no mail is ever send when running tests of Foo.

> This latter technique would probably work in a Layer too...

Right, that might work - I would need to define a test layer in MyLib 
and not forget to use this base layer for the tests for Foo. It would be 
slightly better, but it is still something I or a team member could 
forget. Generally that would not be so much of a problem, however I 
would hate to unintentionally send out mail...

Still I wonder about zope.testing.cleanup...


Thanks for the replies so far!
regards,
jw

___
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] z3c.hashedresource and cache response headers

[Jan-Wijbrand Kolman]

Hi,

We're trying to make an integration of z3c.hashedresource into Grok.

While working on it we wondered how and where people using 
z3c.hashedresource set the caching headers for the resources referenced 
by the URLs generated by z3c.hashedresource.

A few random thoughts about this:

* zope.browserresource.file.FileResource will set cache response headers 
that are more or less hardcoded. Do people just use these values?

* You probably only want to set "aggressive" cache response headers for 
resources that are referred to by the URLs generated by z3c.hashedresource.

Maybe it is an idea to set these headers in the ++noop++ namespace 
handler? (although the name "noop" really isn't suitable anymore then - 
maybe it could be "++cache++" or something).

Any ideas about this?

regards,
jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.hashedresource and cache response headers

[Jan-Wijbrand Kolman]

Hi Stephan,

Stephan Richter wrote:
> On Friday 18 September 2009, Jan-Wijbrand Kolman wrote:
>> While working on it we wondered how and where people using
>> z3c.hashedresource set the caching headers for the resources referenced
>> by the URLs generated by z3c.hashedresource.
> 
> I think I solved that in z3c.versionedresource.

/me looks

If I understand it correctly, you solved the cache response header issue 
by subclassing the resource and resource factory implementations of 
zope.app.publisher.browser.

I guess setting cache response headers for resources could actually be 
factored out of the resource implementation. z3c.versionedresource could 
then make use of that as well.

Hmmm, there's actually an older package called z3c.responseheader that 
does something in that direction - it wouldn't work for resources though 
as they set the cache headers themselves in the GET() and HEAD() methods.

Would it be a good idea to remove setting the cache headers from the 
zope.app.publisher.browser resource implementations and make that more 
pluggable? z3c.versionedresource could then probably get rid of the 
resource subclasses, right?

If people think this is a good idea, I could have a look into it..

regards,
jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] z3c.schema2xml and z3c.schema2json

[Jan-Wijbrand Kolman]

Hi,

I'm about to work a bit on z3c.schema2json [1]. As has been briefly 
discussed before (a while ago [2]), z3c. schema2json is so similar to 
z3c.schema2xml [3] in what it does and how it does it, that I wonder 
about merging the two packages somehow.

One way to do this - maybe - is to use named registrations for the 
(de)serialization adapters. The name could reflect the serialization 
"mode" - for example "xml" or "json".

But maybe there're other ideas to achieve this? Or, could it be that 
merging has no real benefit?

regards,
jw

[1] http://svn.zope.org/Sandbox/paulwilson/z3c.schema2json/
[2] https://mail.zope.org/pipermail/zope-dev/2009-June/037091.html
[3] http://svn.zope.org/z3c.schema2xml/

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] upload zope.app.exception to pypi

[Jan-Wijbrand Kolman]

hello,

Would any of the pypi owners of zope.app.exception be so kind to 
upload the 3.6.0 release to the package index? I see this package has 
been tagged already a while ago.

I think this newer version should also be included in the ZTK versions 
list, as this version will import the correct ISystemErrorView 
interface from zope.browser.

Thank you in advance.

kind regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] upload zope.app.exception to pypi

[Jan-Wijbrand Kolman]

Baiju M  wrote:
> On Mon, Jan 4, 2010 at 6:32 PM, Jan-Wijbrand Kolman
>  wrote:
>> Would any of the pypi owners of zope.app.exception be so kind to
>> upload the 3.6.0 release to the package index? I see this package has
>> been tagged already a while ago.
>>
>> I think this newer version should also be included in the ZTK versions
>> list, as this version will import the correct ISystemErrorView
>> interface from zope.browser.
> 
> I have added "jw" as owner of this package.

Ok, thank you.

> BTW, I am getting this error from 3.6.0 branch.:

Me too.

> $ ./bin/test
> /opt/baiju/wa/z3hello/eggs/zope.testing-3.8.6-py2.6.egg/zope/testing/
testrunner/debug.py:23:
> DeprecationWarning: zope.testing.doctest is deprecated in favour of
> the Python standard library doctest module
>   from zope.testing import doctest
> Test-module import failures:
> 
> Module: zope.app.exception.browser.tests.test_unauthorized
> 
> Traceback (most recent call last):
>   File "/tmp/zope.app.exception/src/zope/app/exception/browser/tests/
test_unauthorized.py",
> line 20, in 
> import zope.app.pagetemplate.namedtemplate
>   File "/opt/baiju/wa/z3hello/eggs/zope.app.pagetemplate-3.10.0-py2.6.egg/
zope/app/pagetemplate/namedtemplate.py",
> line 20, in 
> from zope.browerpage.namedtemplate import implementation
> ImportError: No module named browerpage.namedtemplate

As it turns out, since the "release" of zope.app.exception 3.6.0 namedtemplate 
has again been moved. It is now in zope.browserpage. However, zope.browserpage 
is not required yet by zope.app.exception.

I'll make it require zope.browserpage and release (and upload!) 
zope.app.exception 3.7.0.

Would that be OK?

regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] release and upload zope.app.pagetemplate to pypi

[Jan-Wijbrand Kolman]

hello,

Would any of the owners of zope.app.pagetemplate be so kind to upload 
(or let me upload) a new version of zope.app.pagetemplate?

This will allow me to fix and release zope.app.exception.

regards,
jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] upload zope.app.exception to pypi

[Jan-Wijbrand Kolman]

Jan-Wijbrand Kolman  wrote:
> Baiju M  wrote:
>> $ ./bin/test
>> /opt/baiju/wa/z3hello/eggs/zope.testing-3.8.6-py2.6.egg/zope/testing/
> testrunner/debug.py:23:
>> DeprecationWarning: zope.testing.doctest is deprecated in favour of
>> the Python standard library doctest module
>>   from zope.testing import doctest
>> Test-module import failures:
>> 
>> Module: zope.app.exception.browser.tests.test_unauthorized
>> 
>> Traceback (most recent call last):
>>   File "/tmp/zope.app.exception/src/zope/app/exception/browser/tests/
> test_unauthorized.py",
>> line 20, in 
>> import zope.app.pagetemplate.namedtemplate
>>   File "/opt/baiju/wa/z3hello/eggs/zope.app.pagetemplate-3.10.0-py2.6.egg/
> zope/app/pagetemplate/namedtemplate.py",
>> line 20, in 
>> from zope.browerpage.namedtemplate import implementation
>> ImportError: No module named browerpage.namedtemplate
> 
> As it turns out, since the "release" of zope.app.exception 3.6.0 
> namedtemplate 
> has again been moved. It is now in zope.browserpage. However, 
> zope.browserpage 
> is not required yet by zope.app.exception.

This has been fixed now, but now I'm stumped at this error:

16:17 jw:~/project/grokdev/z.a.exception
$ ./bin/test
/home/jw/project/grokdev/z.a.exception/eggs/zope.testing-3.8.6-py2.5.egg/zope/
testing/testrunner/debug.py:23: DeprecationWarning: zope.testing.doctest is 
deprecated in favour of the Python standard library doctest module
  from zope.testing import doctest
Running zope.app.exception.testing.AppExceptionLayer tests:
  Set up zope.app.exception.testing.AppExceptionLayer Traceback (most recent 
call last):
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.testing-3.8.6-
py2.5.egg/zope/testing/testrunner/runner.py", line 367, in run_layer
setup_layer(options, layer, setup_layers)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.testing-3.8.6-
py2.5.egg/zope/testing/testrunner/runner.py", line 632, in setup_layer
layer.setUp()
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.app.testing-3.7.3-
py2.5.egg/zope/app/testing/functional.py", line 337, in setUp
self.config_file, product_config=self.product_config)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.app.testing-3.7.3-
py2.5.egg/zope/app/testing/functional.py", line 226, in __init__
setup.setUpManager()
  File "/home/jw/project/grokdev/z.a.exception/eggs/
zope.app.securitypolicy-3.5.1-py2.5.egg/zope/app/securitypolicy/browser/tests/
functional.py", line 26, in setUpManager
functional.HTTPCaller()(grant_request, handle_errors=False)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.app.testing-3.7.3-
py2.5.egg/zope/app/testing/functional.py", line 743, in __call__
request = publish(request, handle_errors=handle_errors)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.publisher-3.12.0-
py2.5.egg/zope/publisher/publish.py", line 131, in publish
obj = request.traverse(obj)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.publisher-3.12.0-
py2.5.egg/zope/publisher/browser.py", line 556, in traverse
ob, add_steps = publication.getDefaultTraversal(self, ob)
  File "/home/jw/project/grokdev/z.a.exception/eggs/zope.app.publication-3.10.0-
py2.5.egg/zope/app/publication/browser.py", line 36, in getDefaultTraversal
return ob.browserDefault(request)
Unauthorized: (, 'browserDefault', 
'zope.Security')

I'm trying to figure out what has changed that could be related to this, but if 
anyone has a hint for me...

regards,
jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] release and upload zope.app.pagetemplate to pypi

[Jan-Wijbrand Kolman]

Baiju M  wrote:
 
> On Mon, Jan 4, 2010 at 7:32 PM, Jan-Wijbrand Kolman
>  wrote:
>> hello,
>>
>> Would any of the owners of zope.app.pagetemplate be so kind to upload
>> (or let me upload) a new version of zope.app.pagetemplate?
> 
> Added "jw" as owner.

Thank you. 3.10.1 has been released and uploaded.
regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] upload zope.app.exception to pypi

[Jan-Wijbrand Kolman]

Martijn Faassen  wrote:
> Jan-Wijbrand Kolman wrote:
>> I'm trying to figure out what has changed that could be related to this, but 
if 
>> anyone has a hint for me...
> 
> I can definitely reproduce the error.
> 
> It seems to be occurring somewhere in the setup of the test layer, but 
> strangely enough the publisher kicks in somewhere. I'm curious why the 
> ZTK tests didn't catch this issue (or now the zopeapp tests).

The publisher kicks in because when the layer is setup, the "mgr" user is 
granted the necessary permissions. This is done "TTW" using HTTPCaller(). In 
the 
request string that is passed to it, the basic auth credentials for 
"globalmgr:globalmgrpw" are passed in. 

This however seems not to work (anymore), where, looking at the history of this 
setup code, it had been working for a very long time.

It must be something small and simple I guess, but it is needles and haystacks 
for me at this point...

regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages

[Jan-Wijbrand Kolman]

Martijn Faassen  wrote:
> 25 zope.app packages are broken due to changes in zope.publisher 3.12. 
> zope.publisher had some components factored out of it into zope.login.
> 
> I fixed zope.app.exception: it could be fixed by adding the zope.login 
> requirement and adding a zcml include statement. I suspect most, 
> probably all, other failures are similarly shallow.

I just ran zope.app.exception's test and all pass. Thanks!!

Do I understand correctly here that I can now release zope.app.exception 
too?

regards,
jw




___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages

[Jan-Wijbrand Kolman]

Jan-Wijbrand Kolman  wrote: 
> Martijn Faassen  wrote:
>> 25 zope.app packages are broken due to changes in zope.publisher 3.12. 
>> zope.publisher had some components factored out of it into zope.login.
>> 
>> I fixed zope.app.exception: it could be fixed by adding the zope.login 
>> requirement and adding a zcml include statement. I suspect most, 
>> probably all, other failures are similarly shallow.
> 
> I just ran zope.app.exception's test and all pass. Thanks!!
> 
> Do I understand correctly here that I can now release zope.app.exception 
> too?

Ah, I see you did already as 3.6.1. Thanks.
regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] upload zope.app.exception to pypi

[Jan-Wijbrand Kolman]

Gediminas Paulauskas  wrote:
>> I'll make it require zope.browserpage and release (and upload!)
>> zope.app.exception 3.7.0.

> Could you upload 3.6.0 as it was anyway, the ISystemErrorView move
> would be useful for me since I run SchoolTool on an older/custom
> KGS.

Yes. Done.
regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] z3c.password and "failedAttempts" and SessionCredentialsPlugin

[Jan-Wijbrand Kolman]

Hi,

I'm looking into integrating z3c.password into an application that 
also uses the PAU with the principal folder, InternalPrincipals and 
the SessionCredentialsPlugin.

One of the features of z3c.password that I'd like to use is locking 
out an user account after a number of failed login attempts. 
z3c.password provides such a feature.

However, it seems this feature does not play well with the 
SessionCredentialsPlugin:

The SessionCredentials will store the login and password that were 
submitted through the login form in a session. This login/password 
combination then is checked against the internal principal stored in 
the principal folder.

If the password is correct then (obviously) everything is fine.

When the password is incorrect, the user is directed back to the login 
form as authentication failed. If the page with the login form 
retrieves resources (like images or css of javascript files) and since 
the zopepublication will _try_ to authenticate every request, the 
wrongful login/password combination is checked multiple times for that 
page and its resources against the internal principal object.

The internal principal mixin of z3c.password will count the number of 
failed checks. If you tell it to lock out an user after, say, three 
failed attempts, you have a problem, as the number of login page 
resources (thus requests) will quite easily outnumber the maximum 
number of attempts.

Questions: is anyone using this feature of z3c.password in combination 
with the SessionCredentialsPlugin? If this is working for you, do you 
have any idea what I am doing wrong here? What type of authentication 
are the authors of z3c.password using?

Thanks for any insight here.
regards,
jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and "failedAttempts" andSessionCredentialsPlugin

[Jan-Wijbrand Kolman]

"Roger"  wrote:
>> Betreff: [Zope-dev] z3c.password and "failedAttempts" 
>> andSessionCredentialsPlugin
>> 
>> I'm looking into integrating z3c.password into an application 
>> that also uses the PAU with the principal folder, 
>> InternalPrincipals and the SessionCredentialsPlugin.
>> 
>> One of the features of z3c.password that I'd like to use is 
>> locking out an user account after a number of failed login attempts. 
>> z3c.password provides such a feature.
>> 
>> However, it seems this feature does not play well with the
>> SessionCredentialsPlugin:
>> 
>> The SessionCredentials will store the login and password that 
>> were submitted through the login form in a session. This 
>> login/password combination then is checked against the 
>> internal principal stored in the principal folder.
>> 
>> If the password is correct then (obviously) everything is fine.
>> 
>> When the password is incorrect, the user is directed back to 
>> the login form as authentication failed. If the page with the 
>> login form retrieves resources (like images or css of 
>> javascript files) and since the zopepublication will _try_ to 
>> authenticate every request, the wrongful login/password 
>> combination is checked multiple times for that page and its 
>> resources against the internal principal object.
>> 
>> The internal principal mixin of z3c.password will count the 
>> number of failed checks. If you tell it to lock out an user 
>> after, say, three failed attempts, you have a problem, as the 
>> number of login page resources (thus requests) will quite 
>> easily outnumber the maximum number of attempts.
>> 
>> Questions: is anyone using this feature of z3c.password in 
>> combination with the SessionCredentialsPlugin? If this is 
>> working for you, do you have any idea what I am doing wrong 
>> here? What type of authentication are the authors of 
>> z3c.password using?
> 
> Probably Adam can tell you more about that.

I hope so :-) At this point I do not see how this feature can work except 
with PAU's BasicAuth - or in tests, where the page's resources generally 
are not fetched and this the problem is not exposed...

> One solution could be to offload your resources and 
> deliver them from Apache or Nginx Frontend.

This might work for generic resources in a page, but not for, for 
example, images in the page or something that needed computation. It 
would essentially only counter the symptoms.

Thanks you for your reply.

regards,
jw




___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and "failedAttempts" andSessionCredentialsPlugin

[Jan-Wijbrand Kolman]

Adam GROSZER  wrote:

Thank you for your reply!

> Right. Well right now the lame solution is to try to count the number
> of resources needed to load the page and multiply maxFailedAttempts by
> that number.
> Other than that you _will_ want to offload resources in production.

Oh, sure in _production_ I will. But what about testing and development. And 
counting the number of resources is highly unpredictable - esp. as I'm working 
on applications that can be easily skinned for different clients.

> (An other idea could be to try to identify requests that are not for
> resources, but how?)

There's no real way as far as I can tell :|

Even worse, if Zope were to handle one or more login page requisites, you can 
easily get database write conflicts as multiple "simultaneous" requests will 
try 
to increase the failed login attempts counter on the internal principal object.

Can I conclude this particular feature of z3c.password is not really in use by 
anyone else (at least not in combination with the SessionCredentialsPlugin)?

regards,
jw

> Tuesday, January 19, 2010, 12:16:38 AM, you wrote:
>>> Betreff: [Zope-dev] z3c.password and "failedAttempts" 
>>> andSessionCredentialsPlugin
>>> 
>>> Hi,
>>> 
>>> I'm looking into integrating z3c.password into an application 
>>> that also uses the PAU with the principal folder, 
>>> InternalPrincipals and the SessionCredentialsPlugin.
>>> 
>>> One of the features of z3c.password that I'd like to use is 
>>> locking out an user account after a number of failed login attempts. 
>>> z3c.password provides such a feature.
>>> 
>>> However, it seems this feature does not play well with the
>>> SessionCredentialsPlugin:
>>> 
>>> The SessionCredentials will store the login and password that 
>>> were submitted through the login form in a session. This 
>>> login/password combination then is checked against the 
>>> internal principal stored in the principal folder.
>>> 
>>> If the password is correct then (obviously) everything is fine.
>>> 
>>> When the password is incorrect, the user is directed back to 
>>> the login form as authentication failed. If the page with the 
>>> login form retrieves resources (like images or css of 
>>> javascript files) and since the zopepublication will _try_ to 
>>> authenticate every request, the wrongful login/password 
>>> combination is checked multiple times for that page and its 
>>> resources against the internal principal object.
>>> 
>>> The internal principal mixin of z3c.password will count the 
>>> number of failed checks. If you tell it to lock out an user 
>>> after, say, three failed attempts, you have a problem, as the 
>>> number of login page resources (thus requests) will quite 
>>> easily outnumber the maximum number of attempts.
>>> 
>>> Questions: is anyone using this feature of z3c.password in 
>>> combination with the SessionCredentialsPlugin? If this is 
>>> working for you, do you have any idea what I am doing wrong 
>>> here? What type of authentication are the authors of 
>>> z3c.password using?
> 
> R> Probably Adam can tell you more about that.
> 
> R> One solution could be to offload your resources and 
> R> deliver them from Apache or Nginx Frontend.
> 
> R> Regards
> R> Roger Ineichen
> 
>>> Thanks for any insight here.
>>> regards,
>>> jw
>>> 
>>> 
>>> 
>>> ___
>>> Zope-Dev maillist  -  Zope-Dev@zope.org
>>> https://mail.zope.org/mailman/listinfo/zope-dev
>>> **  No cross posts or HTML encoding!  ** (Related lists -  
>>> https://mail.zope.org/mailman/listinfo/zope-announce
>>>  https://mail.zope.org/mailman/listinfo/zope )
>>> 
> 
> R> ___
> R> Zope-Dev maillist  -  Zope-Dev@zope.org
> R> https://mail.zope.org/mailman/listinfo/zope-dev
> R> **  No cross posts or HTML encoding!  **
> R> (Related lists - 
> R>  https://mail.zope.org/mailman/listinfo/zope-announce
> R>  https://mail.zope.org/mailman/listinfo/zope )
> 
> -- 
> Best regards,
>  Adam GROSZERmailto:agros...@gmail.com
> 


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] quitting the ZTK steering group

[Jan-Wijbrand Kolman]

Martijn Faassen  wrote:
> Hi there,
> 
> This is to announce my withdrawal from the Zope Toolkit steering
> group.

I'm not sure if you're reading this, but I wanted to thank you anyway 
for the tremendous amount of energy you've put into the steering 
group.

kind regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.app.authentication

[Jan-Wijbrand Kolman]

Hi, 

Christian Theune  wrote:
> On 01/26/2010 09:32 AM, Souheil CHELFOUH wrote:
>> I hear you and understand you.
> 
> Thanks. :)
> 
>> I'm not advertizing for an immediate and brainless action.
>> What I did this week end is simply to split the PAU from all the
>> components provided with it (well, most of it).
>> That was motivated by my current work and by the will to see the
>> dependencies become cleaner and the code shorter.
>> I understand that the momentum is not everything, but when I can
>> dedicate myself to a task, be motivated by it and paid for it, then, I
>> don't see any reasons to hold back ;-)
> 
> Right. That's pretty much how I feel myself. ;)
> 
>> In this case, I'll just wait for your feedbacks, zope devs, and we'll
>> take the time (obviously) to do the things correctly.
> 
> I know that it's always nice to be able to immediately reap the fruits
> from your work and I hate it having to go with "about to be outdated"
> code with a project, but in the long run some patience will get us further.
> 
> Thanks for understanding!
> 
>> Let me know what you guys think, about what has to be done, when you can
> 
> Something we need to sort out is keeping "open reviews" or "open
> proposals" on the radar.
> 
> Can you please add a blueprint here:
> https://blueprints.launchpad.net/zopetoolkit/
> 
> Also, can you add a proposal page to the documentation that points out
> what you already implemented and what you intend to achieve globally?

Just my quick 2 euro cents here:

As far as I can tell, what Souheil did so far is no architectural change, but a 
change like so many in the recent past where a zope.app.something package has 
been refactored into a zope.something package and keeping backwards 
compatibility in zope.app.something.

I'm not sure how this became looking way bigger than it is, except for the 
explicit requests for feedback by Souheil. He requested feedback, I guess, as 
he 
might not yet be completely confident about making these changes and needs some 
support - I can fully understand that myself.


regards,
jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.app.authentication

[Jan-Wijbrand Kolman]

Hi,

Christian Theune  wrote:
> On 01/26/2010 03:30 PM, Souheil CHELFOUH wrote:
>> Well, the first step is already to cut the dependencies and get a sane
>> tree and a reusable package.
>> The second step, however, if people feel like it, will be to refactor
>> a bit and _that_ will need careful planning, yes.
>> But, one thing at a time :)
>> 
>> However, I'll polish a bit zope.plugabbleauth and it will be eligible
>> for a release, I guess.
> 
> Sounds like a plan. :)

Cool! 

regards,
jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] bugfix release for zope.app.wsgi, pypi rights

[Jan-Wijbrand Kolman]

Hi, 

I'd like to make a 3.6.1 bugfix release for zope.app.wsgi.

On the trunk there's support for picking up "product configuration" 
that has not been released yet (however, it had been released in a 
bugfix release in the 3.4 line).

Could I ask someone to grant me pypi rights for this package?

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] bugfix release for zope.app.wsgi, pypi rights

[Jan-Wijbrand Kolman]

Marius Gedminas  wrote:
 
> Marius Gedminas  wrote:
 
> Marius Gedminas  wrote:
 
> On Fri, Jan 29, 2010 at 10:48:41AM +0000, Jan-Wijbrand Kolman wrote:
>> I'd like to make a 3.6.1 bugfix release for zope.app.wsgi.
>> 
>> On the trunk there's support for picking up "product configuration" 
>> that has not been released yet (however, it had been released in a 
>> bugfix release in the 3.4 line).
>> 
>> Could I ask someone to grant me pypi rights for this package?
> 
> It is a very good idea to include the stock phrase "my PyPI username is
> ..." in any such request.

Yes it is. Sorry, forgot.

  My PyPI username is jw

Thanks :-)

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and "failedAttempts" andSessionCredentialsPlugin

[Jan-Wijbrand Kolman]

Hi Adam,

Tres Seaver  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Adam GROSZER wrote:
> 
>> Thinking this further, resource requests will have a '/@@/' (usually)
>> in their URL. So it might be an idea to skip those requests from
>> counting.
> 
> Seems to me skipping anything except POST requests would be the right
> thing to do:  suppose the user reloads the login form for some reason
> (maybe their browser crashes, whatever).

I see you're working on this issue. That's fantastic. If you need a 
tester... by all means let me know :-)

regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and "failedAttempts" andSessionCredentialsPlugin

[Jan-Wijbrand Kolman]

Hi Adam,

Adam GROSZER  wrote:
> We're using it too...
> Go for 0.8.0.

I noticed that requesting for, for example, a resource could still trigger
account locked errors, where in my opinion only the login attempts
themselves should do that.

I created a branch...

  http://svn.zope.org/z3c.password/branches/jw-noraise-for-irrelevant-requests/

..that will check for request relevancy as early as possible.

All tests pass without modification, but still, after an account has been 
locked 
requests for, for example resources, will still work (the diff against the 
trunk 
is pasted below). Additionally I think the code is tad more readable now.

I realize now that I should add a test to demonstrate this.

Anyway, could you tell me what you think of this approach?

regards, jw




--- z3c.password-trunk/src/z3c/password/principal.py
2010-02-04 12:15:46.632785192 +0100
+++ z3c.password/src/z3c/password/principal.py  2010-02-04 12:08:56.351805021 
+0100
@@ -13,7 +13,7 @@
 ##
 """Principal MixIn for Advanced Password Management
 
-$Id: principal.py 108644 2010-01-29 17:28:55Z adamg $
+$Id: principal.py 108749 2010-02-04 11:08:55Z janwijbrand $
 """
 __docformat__ = "reStructuredText"
 import datetime
@@ -81,6 +81,30 @@
 #hook to facilitate testing and easier override
 return datetime.datetime.now()
 
+def _isIrrelevantRequest(self, RELEVANT=False, IRRELEVANT=True):
+fac = self._failedAttemptCheck()
+if fac is None:
+return RELEVANT
+
+if fac == interfaces.TML_CHECK_ALL:
+return RELEVANT
+
+interaction = getInteraction()
+try:
+request = interaction.participations[0]
+except IndexError:
+return RELEVANT # no request, we regard that as relevant.
+
+if fac == interfaces.TML_CHECK_NONRESOURCE:
+if '/@@/' in request.getURL():
+return IRRELEVANT
+return RELEVANT
+
+if fac == interfaces.TML_CHECK_POSTONLY:
+if request.method == 'POST':
+return RELEVANT
+return IRRELEVANT
+
 def checkPassword(self, pwd, ignoreExpiration=False, ignoreFailures=False):
 # keep this as fast as possible, because it will be called (usually)
 # for EACH request
@@ -88,6 +112,11 @@
 # Check the password
 same = super(PrincipalMixIn, self).checkPassword(pwd)
 
+# Do not try to record failed attempts or raise account locked
+# errors for requests that are irrelevant in this regard.
+if self._isIrrelevantRequest():
+return same
+
 if not ignoreFailures and self.lastFailedAttempt is not None:
 if self.tooManyLoginFailures():
 locked = self.accountLocked()
@@ -118,7 +147,9 @@
 add = 0
 else:
 #failed attempt, record it, increase counter
-add = self.checkFailedAttempt()
+self.failedAttempts += 1
+self.lastFailedAttempt = self.now()
+add = 1
 
 # If the maximum amount of failures has been reached notify the
 # system by raising an error.
@@ -133,45 +164,6 @@
 
 return same
 
-def _getRequest(self):
-interaction = getInteraction()
-try:
-return interaction.participations[0]
-except IndexError:
-return None
-
-def checkFailedAttempt(self):
-#failed attempt, record it, increase counter (in case we have to)
-validRequest = True
-fac = self._failedAttemptCheck()
-if fac == interfaces.TML_CHECK_ALL:
-validRequest = True
-else:
-request = self._getRequest()
-if request is None:
-validRequest = True
-else:
-if fac == interfaces.TML_CHECK_NONRESOURCE:
-url = request.getURL()
-if '/@@/' in url:
-#this is a resource
-validRequest = False
-else:
-validRequest = True
-elif fac == interfaces.TML_CHECK_POSTONLY:
-if request.method == 'POST':
-#this is a POST request
-validRequest = True
-else:
-validRequest = False
-
-if validRequest:
-self.failedAttempts += 1
-self.lastFailedAttempt = self.now()
-return 1
-else:
-return 0
-



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] release for z3c.password with Dutch translations

[Jan-Wijbrand Kolman]

Hello,

I would be greatly helped with a new release of z3c.password with the
Dutch translations that I recently added.

Would it be possible for one of the package owners to make a release, 
or, alternatively, allow me to upload a new version to the package 
index? (My pypi username is jw).

Thank you very much!
regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] release for z3c.password with Dutch translations

[Jan-Wijbrand Kolman]

Michael Howitz  wrote:
>> Would it be possible for one of the package owners to make a release, 
>> or, alternatively, allow me to upload a new version to the package 
>> index? (My pypi username is jw).
> 
> Done.

Thanks!
I just released z3c.password 0.9.0.
regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] z3c.password and tracking failed login attempts

[Jan-Wijbrand Kolman]

Hi,

A while ago I asked some questions and made some suggestions for improving how 
to track failed login attempts in z3c.password. Most likely these suggestions 
got buried in now a out-of-sight thread and were never noticed.

My suggestion was that making a request for for example a resource could still 
trigger the account locked errors, where in my opinion only the login attempts 
themselves should do that.
 
I created a branch of z3c.password..: 
 
  http://svn.zope.org/z3c.password/branches/jw-noraise-for-irrelevant-requests/ 
 
..that will check for request relevancy as early as possible. 
 
All tests pass without modification, but with this change after an account has 
been locked out requests for for example resources will still work. 
Additionally 
I think the code is a tad more readible now. I added a test to demonstrate the 
specific behaviour.
 
Would any of the z3c.password users/developers object to having this branch 
merged to the trunk?

regards, jw 



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and tracking failed login attempts

[Jan-Wijbrand Kolman]

Adam GROSZER  wrote:
> Looks good.
> 
> The only weird is to define those constants in the method parameters.
> 
> def _isIrrelevantRequest(self, RELEVANTlse, IRRELEVANTue):
> 
> Do you call this method from somewhere else?
> 
> Maybe it would be better to change the name (and behavour) to
> _isRelevantRequest and go with plain True/False instead of those
> constants.

Hmm, right. I'd hoped to make it more understandable what "True" meant 
and what "False" meant in this context. But by changing the name of the 
method itself, it'll probably just as good. I'll change that and then 
merge it with the trunk.

I'll make a release of z3c.password then too, if you agree with that.

regards, and thanks,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.password and tracking failed login attempts

[Jan-Wijbrand Kolman]

Adam GROSZER  wrote:
> JWK> I'll make a release of z3c.password then too, if you agree with that.
> 
> Sure. I'd go with a minor version increment. E.g. 0.10.1.

We were at 0.9.0, I made it a 0.10.0.

Great for having these features available!!

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] How to make Zope fail nicely under high load?

[Jan-Wijbrand Kolman]

Bjorn Stabell wrote:
(..)For ZEO, my understanding is that we would still have to store the
values in the ZODB, though.
You are able to store *and* share data over ZEO Clients in a
TemporaryStorage by making the ZSS serve this TemporaryStorage to its
ZCs. You could mount this storage as temp_folder I guess, but any
other mount point would work too.
Not sure, but I'd expect so, whether this has significant perfomance
advantages over a 'normal' ZODB served by the ZSS.
regards,
jw
--
Jan-Wijbrand Kolman
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: "RewriteMap"s inefficient

[Jan-Wijbrand Kolman]

Ganesha Shanmuganathan wrote:
(..)Is there anyother way to do load balncing with Zope
without Rewrite ?
Not sure, but would this help?
http://www.backhand.org/mod_backhand/
regards
jw
--
Jan-Wijbrand Kolman
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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] inconsistent mimetype assignment for uploaded files

[Jan-Wijbrand Kolman]

Hello,
we recently realised mimetype assignment in Zope to e.g. Zope File
objects is inconsistent and can vary when different clients (browsers)
upload files with the same file extensions.
Example: when a file called "foobar.rtf" is upload to a Zope File
object from Linux Firefox, the mimetype assigned is (can be)
'application/rtf'. However, the same file uploaded to the same Zope
File object in the same Zope instance, using IE on Window2000 (with MS
Office installed) will get 'application/msword' assigned.
The mimetype assignment for uploaded files is done in OFS.Image.py
(maybe there're more places or other Products that do this - I know
that at least ExtFile does this too). line 463 of OFS.Image.py, Zope
2.7.2:
def _get_content_type(self, file, body, id, content_type=None):
headers=getattr(file, 'headers', None)
if headers and headers.has_key('content-type'):
content_type=headers['content-type']
else:
if type(body) is not type(''): body=body.data
content_type, enc=guess_content_type(
getattr(file, 'filename',id), body, content_type)
return content_type
Then I understood that the headers as sent by the client for this file
(may?) have a content-type entry that takes precedence over both the
mimetypes 'database' and the content_type passed in as an argument.
We could deal with the inconsistent assignment on the application
level (in this case Silva), but I'd rather consider changing this
behaviour on the Zope level. I could imagine changing the way a
mimetype is 'guessed' from an uploaded File to something like:
def _get_content_type(self, file, body, id, content_type=None):
"""
Order of precedence:
1) see if guess_content_type resolves to a mimetype for the
   filename
2) if not use content_type as sent in the headers if
   available
3) else use argument passed in
"""
headers = getattr(file, 'headers', {})
content_type = headers.get('content-type', content_type)
if type(body) is not type(''):
body = body.data
name = getattr(file, 'filename', id)
content_type, enc = guess_content_type(name, body, content_type)
return content_type
Does anyone have an opinion on this? Is the current behaviour
completely intentional, maybe even according to some specification
(and thus I should deal with it on the application level)? Should I
file a collector issue?
regards
jw
--
Jan-Wijbrand Kolman
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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: inconsistent mimetype assignment for uploaded files

[Jan-Wijbrand Kolman]

Tres Seaver wrote:
-1 for using the "guessed" value over the one from the headers;  +1 for 
using the argument over the guessed value (so that the application can 
"fix" the problem).  I agree that having different clients supply 
different types is painful, but I don't think that "fixing" it at the 
low level is reasonable (mechanism vs. policy).
Can you elaborate a bit more on the "mechanism vs. policy" remark? I'm
not sure I understand your line or reasoning and I'm curious for it :)
regards,
jw
--
Jan-Wijbrand Kolman
[EMAIL PROTECTED]
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
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.intid and zope.keyreference.interfaces.NotYet exception (patch)

[Jan-Wijbrand Kolman]

On 1/24/12 23:49 , Cykooz wrote:
> 2012/1/25 Marius Gedminas :
>>
>> http://foundation.zope.org/agreements is where you can find the
>> committer agreement form.
> 
> Thanks.
> But I have one problem. I do not know any of the existing Committer
> who can vouch for me.

Bringing up a rather old thread:

Cykooz, was there any kind of follow up on this discussion? Are you
basically using a forked zope.keyreference for the time being?

Kind regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.intid and zope.keyreference.interfaces.NotYet exception (patch)

[Jan-Wijbrand Kolman]

On 7/3/12 13:26 , Cykooz wrote:
> 2012/7/3 Jan-Wijbrand Kolman  <mailto:janwijbr...@gmail.com>>
> 
> Are you basically using a forked zope.keyreference for the time being?
> 
>  No, I do not use a forked zope.keyreference. I used my fork of the
> zope.intid.

Ah, yes of course, that's what I meant: zope.intid.

I would not consider myself in a position currently to vouch for you to
have comitter rights. I do however wonder if anyone else would like to
comment on your proposed change.

If the comments a favorable I could try to help apply the patch to
zope.intid. This would probably help me and you as you then would not
have to use a forked package anymore.

At the end of this post, I pasted the diff from the current zope.intid
trunk against your "fork" on bitbucket. Maybe this would make it easier
for others to comment on it?

regards, jw


Proposed patch:
===

diff -u zope.intid/trunk/src/zope/intid//__init__.py
zope.intid-cykooz/src/zope/intid//__init__.py
--- zope.intid/trunk/src/zope/intid//__init__.py2012-07-03
11:56:11.576511518 +0200
+++ zope.intid-cykooz/src/zope/intid//__init__.py   2012-07-03
11:55:17.261865415 +0200
@@ -19,12 +19,14 @@
 This functionality can be used in cataloging.
 """
 import random
+import threading
+from weakref import WeakKeyDictionary, WeakSet

 import BTrees
 from persistent import Persistent
 from zope.component import adapter, getAllUtilitiesRegisteredFor,
subscribers
 from zope.event import notify
-from zope.interface import implementer
+from zope.interface import implements
 from zope.keyreference.interfaces import IKeyReference, NotYet
 from zope.lifecycleevent.interfaces import IObjectAddedEvent
 from zope.lifecycleevent.interfaces import IObjectRemovedEvent
@@ -32,16 +34,16 @@
 from zope.location.interfaces import IContained
 from zope.security.proxy import removeSecurityProxy

-from zope.intid.interfaces import IIntIds, IIntIdEvent
+from zope.intid.interfaces import IIntIds, IIntIdEvent, IIntIdsDisabled
 from zope.intid.interfaces import IntIdAddedEvent, IntIdRemovedEvent

-@implementer(IIntIds, IContained)
 class IntIds(Persistent):
 """This utility provides a two way mapping between objects and
 integer ids.

 IKeyReferences to objects are stored in the indexes.
 """
+implements(IIntIds, IContained)

 __parent__ = __name__ = None

@@ -136,6 +138,10 @@
 del self.ids[key]


+thread_data = threading.local()
+thread_data.deferred_objects = WeakKeyDictionary()
+
+
 @adapter(ILocation, IObjectRemovedEvent)
 def removeIntIdSubscriber(ob, event):
 """A subscriber to ObjectRemovedEvent
@@ -143,9 +149,22 @@
 Removes the unique ids registered for the object in all the unique
 id utilities.
 """
+
 utilities = tuple(getAllUtilitiesRegisteredFor(IIntIds))
 if utilities:
-key = IKeyReference(ob, None)
+try:
+key = IKeyReference(ob, None)
+except NotYet:
+deferred_objects = thread_data.deferred_objects
+if ob in deferred_objects:
+del deferred_objects[ob]
+parent = getattr(ob, '__parent__', None)
+if parent in deferred_objects and ob in
deferred_objects[parent]:
+deferred_objects[parent].remove(ob)
+if len(deferred_objects[parent]) == 0:
+del deferred_objects[parent]
+return
+
 # Register only objects that adapt to key reference
 if key is not None:
 # Notify the catalogs that this object is about to be removed.
@@ -156,6 +175,7 @@
 except KeyError:
 pass

+
 @adapter(ILocation, IObjectAddedEvent)
 def addIntIdSubscriber(ob, event):
 """A subscriber to ObjectAddedEvent
@@ -163,16 +183,46 @@
 Registers the object added in all unique id utilities and fires
 an event for the catalogs.
 """
+
 utilities = tuple(getAllUtilitiesRegisteredFor(IIntIds))
 if utilities: # assert that there are any utilites
+register_object(ob, utilities, event)
+
+
+def register_object(ob, utilities, event):
+deferred_objects = thread_data.deferred_objects
+intids_enabled = not IIntIdsDisabled.providedBy(ob)
+try:
 key = IKeyReference(ob, None)
-# Register only objects that adapt to key reference
-if key is not None:
-idmap = {}
-for utility in utilities:
-idmap[utility] = utility.register(key)
-# Notify the catalogs that this object was added.
-notify(IntIdAddedEvent(ob, event, idmap))
+except NotYet:
+if intids_enabled:
+parent = getattr(ob, '__parent__', None)
+if parent is None:
+raise
+if parent not in deferred_objects:
+  

Re: [Zope-dev] zope.intid and zope.keyreference.interfaces.NotYet exception (patch)

[Jan-Wijbrand Kolman]

On 7/3/12 15:06 , Hanno Schlichting wrote:
> On Tue, Jul 3, 2012 at 1:56 PM, Jan-Wijbrand Kolman
>  wrote:
>> At the end of this post, I pasted the diff from the current zope.intid
>> trunk against your "fork" on bitbucket. Maybe this would make it easier
>> for others to comment on it?
> 
> It would be easier to read if you did the diff against the base
> version the fork was started from. Or otherwise update the fork with
> the changes done in the meantime.
> 
> I see a bunch of unrelated changes in there, like the
> implements/implementer changes. I'm not sure what else is unrelated to
> the proposed change.

Ow, well, yes you are right. I didn't investigate too deeply either and
I do not know the revision the fork was based on. Maybe I just didn't
look hard enough.

I just wanted to see if we could get a little feedback by posting the
diff over here, instead for others to have to go through this just see
what the proposed changes are. Being the messenger so to say.

Did you stop looking at the diff once you noticed it was created
suboptimally? Would it help to find out the base revision and post a
diff again? I guess Cykooz would know the revision of the common base?

regards, jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] zope.formlib's action decorator return Action() object, not the decorated function. Why?

[Jan-Wijbrand Kolman]

Hi,

After years and years of heavily using zope.formlib it suddenly struck
me that the zope.formlib.form.action decorator returns an Action()
object instead of the decorated function (this action object is also
added to the form's actions sequence as a "side effect" of the decorator).

I know wonder: Why?

I cannot find a use case for wanting the action object added to the
class members under the name of the decorated function. But maybe there is?

The reason I came across this "issue" is trying to improve the test
coverage of the application I'm building somewhat closer to 100% and
found that the form actions implementation *appeared* not to be covered
at all - even if there clearly are tests for these.

I tried having the decorator "just" returning the function, and at least
all zope.formlib's tests themselves do pass.

Would anyone mind if I would change the behaviour of the decorator?

Kind regards, jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.formlib's action decorator return Action() object, not the decorated function. Why?

[Jan-Wijbrand Kolman]

On 9/16/12 07:28 , Marius Gedminas wrote:
> On Fri, Sep 14, 2012 at 01:44:30PM +0200, Jan-Wijbrand Kolman wrote:
>> The reason I came across this "issue" is trying to improve the test
>> coverage of the application I'm building somewhat closer to 100% and
>> found that the form actions implementation *appeared* not to be covered
>> at all - even if there clearly are tests for these.
> 
> How are you measuring coverage?

The coverage reports as generated by the zope.testrunner ``--coverage``
option, then z3c.coverage to render the reports into html.

> How are you testing the handlers?

In this specific case, I noticed the handlers seemed not be called
(according to the coverage report) when using a test browser
"submitting" a form.

But I didn't try anything else just yet except for running that test
again with a patched zope.formlib - where the decorated would return the
function - and then the coverage was up :-)

> I'm asking because I haven't encountered this issue in my projects --
> form action handlers show up in my test coverage just fine.
> 
>> I tried having the decorator "just" returning the function, and at least
>> all zope.formlib's tests themselves do pass.
>>
>> Would anyone mind if I would change the behaviour of the decorator?
> 
> I have unit tests that invoke view.handle_foo_button.handler() directly,
> because they assume zope.formlib's @action replaces the
> handle_foo_button method with an Action.  Your change would break my
> tests, but they would be trivial to fix, so my vote would be -0, with
> the request of a larger version bump to indicate backwards-incompatibility.

Ok, clear.

Thanks for the feedback!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.formlib's action decorator return Action() object, not the decorated function. Why?

[Jan-Wijbrand Kolman]

On 9/16/12 09:38 , Wichert Akkerman wrote:
> On Sep 16, 2012, at 07:28, Marius Gedminas  wrote:
> 
>> On Fri, Sep 14, 2012 at 01:44:30PM +0200, Jan-Wijbrand Kolman wrote:
>>> After years and years of heavily using zope.formlib it suddenly struck
>>> me that the zope.formlib.form.action decorator returns an Action()
>>> object instead of the decorated function (this action object is also
>>> added to the form's actions sequence as a "side effect" of the decorator).
>>>
>>> I know wonder: Why?
>>
>> (I've no clue.)
> 
> Another effect of this is probably that you can use sphinx's autodoc for 
> actions which would be unfortunate.

Ah, good catch. Didn't think of that yet...
regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ZTK 2.0 process

[Jan-Wijbrand Kolman]

Hi,

On 2/26/13 5:04 PM, Hanno Schlichting wrote:
> Hi.
> 
> The process for a ZTK 2.0 release isn't really well defined. I'm not
> sure if Jan-Wijbrand and Christophe are still interested in working on
> ZTK releases.

I'm personally and from a business-perspective still interested in the
ZTK and to have Grok to be a relevant (to the ZTK process) "consumer" of
the ZTK.

That said, I've been off of the radar for a while concerning the ZTK
because: 1) busy and 2) Grok's proven to be fairly stable and thus did
not need much maintenance for quite a while.

So:

* Thanks Stephan and Hanno to get this ball rolling again

* Thanks to whoever ported so many of the ZTK packages to Python 3 already!

* I'll need to blow of some dust from my ZTK-knowledge and how Grok is
using it to give you useful input to your questions.

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] ZTK 2.0 process

[Jan-Wijbrand Kolman]

Hi,

On 2/26/13 7:26 PM, Hanno Schlichting wrote:
snip
> Our rule for inclusion in the ZTK is: Whatever library is used by at
> least two out of the three frameworks (BlueBream, Grok, Zope).
> 
> Given that BlueBream hasn't seen any release beyond a 1.0 about two
> years back, I'm not sure it's active or relevant anymore. Grok isn't
> seeing frequent releases, but there was a 1.5.5 mid last year.
> 
> If you compare the version list from the last ZTK 1.1.5
> (http://download.zope.org/zopetoolkit/index/1.1.5/zopeapp-versions.cfg)
> and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg),
> you'll notice that Grok already overwrites the version requirement for
> half of the non-deprecated packages with its own versions. And as I
> said, Zope isn't using any of them anymore for a long time.
> 
> So I don't see any value in testing and promising stability for those
> zope.app packages, when there aren't any shared consumers for the
> specific versions.
> 
> And the actually used versions by Grok are:
> zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug -
> renaming those to a non zope.app prefix doesn't make a lot of sense
> for me either - as they are all about a specific app server
> configuration and not generally reusable libraries.

Agreed, from a Grok perspective: if there is no shared interested
anymore in the zope.app.* packages, Grok will need to take up
maintainership for those itself. In a way we already did by upping the
versions of several of those package already.

The zope.app.* packages that really are in use for a vanilla Grok-based
application are zope.app.applicationcontrol, zope.app.appsetup and
zope.app.debug and zope.app.wsgi.

If there would be a strong drive from the Grok community to have Python
3 compatibility, they (and that includes me :) ) should port those
zope.app.* packages or build the equivalents.

I'll make note of this on the Grok dev list as well.

regards, jw





___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

Hi,

Disclaimer: it's been a while since I actively followed zope-dev and 
grok-dev. So, please forgive me my ignorance.


Spurred by the recent ZTK-2.0 discussion, I'm trying to get back on 
track on the topics of 1) migrating package to github and 2) porting 
packages to Python 3.


As a first step, I'd like to get the packages directly related to Grok 
moved over to github.


Could someone perhaps tell me if there's a guideline document, some kind 
of recipe, or perhaps a "conclusive" posting on the mailinglist on how 
to proceed on this topic?


Thanks in advance for any pointers!!

kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

On 3/1/13 10:17 AM, Marius Gedminas wrote:

On Fri, Mar 01, 2013 at 09:51:05AM +0100, Jan-Wijbrand Kolman wrote:

Disclaimer: it's been a while since I actively followed zope-dev and
grok-dev. So, please forgive me my ignorance.


A single up-to-date web page sure beats reading months of list archives.


:-)


Spurred by the recent ZTK-2.0 discussion, I'm trying to get back on
track on the topics of 1) migrating package to github and 2) porting
packages to Python 3.

As a first step, I'd like to get the packages directly related to
Grok moved over to github.

Could someone perhaps tell me if there's a guideline document, some
kind of recipe, or perhaps a "conclusive" posting on the mailinglist
on how to proceed on this topic?


My attempt at this: https://gist.github.com/mgedmin/4944724

AFAIK Stephan migrated most of the zope.* packages using this process.


Ok, thanks. I've read it, but will need to re-read it a couple of times 
more I guess :)


It seem to me the best next step would be to just pick a random 
grokcore.* package and to just try it. I'll pick, well, grokcore.component.


If I understand correctly, there's two things I need to ask "someone" to do:

* create a repository at https://github/zopefoundation/grokcore.component

* ask permission to use the authors.txt mapping svn usernames to real 
names and email addresses.


Again, thanks for the information.

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

On 3/1/13 2:23 PM, Marius Gedminas wrote:

On Fri, Mar 01, 2013 at 11:24:31AM +0100, Jan-Wijbrand Kolman wrote:

On 3/1/13 10:17 AM, Marius Gedminas wrote:

My attempt at this: https://gist.github.com/mgedmin/4944724

AFAIK Stephan migrated most of the zope.* packages using this process.


Stephan tells me there are scripts at
https://github.com/zopefoundation/zope.githubsupport
that can do the entire process (create repo, convert history, upload
it), if you've the right permissions on Github (few people do).  So
perhaps the easiest thing is to ask for the package to be converted.


I just read Stephan's reply pointing to that script.

I have no idea whether I have the right permissions.

I do see someone just created an empty grokcore.component repository on 
github (thanks whoever did that! :-)  )


I could surely ask others to do the work for me, though I had the 
impression everyone could take care of the packages he/she cares about :-)


The list that I intended to start off with is roughly:

   grok
   grokcore.annotation
   grokcore.catalog
   grokcore.chameleon
   grokcore.component
   grokcore.content
   grokcore.formlib
   grokcore.json
   grokcore.layout
   grokcore.message
   grokcore.rest
   grokcore.security
   grokcore.site
   grokcore.startup
   grokcore.traverser
   grokcore.view
   grokcore.viewlet
   grokcore.xmlrpc
   grokproject
   grokui.admin
   grokui.base
   martian
   megrok.menu
   zope.errorview
   zope.fanstatic
   z3c.autoinclude
   z3c.evalexception
   z3c.flashmessage
   zc.catalog

Since the grokcore.component repo is there now, I'll follow my initial 
plan and try to get that migrated from svn to github as a first step.


kind regards, jw




___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

On 3/1/13 1:39 PM, Stephan Richter wrote:

AFAIK Stephan migrated most of the zope.* packages using this process.


Yes, I have, except that I use a one does it all script published here:

https://github.com/zopefoundation/zope.githubsupport


Aha, great!


All you need to do is to create a zope.cfg that works for you. I can quickly
create repositories for you if you send me a list of (pkg_name, pkg_title)
tuples.


I just compiled a list in another reply in this thread.


Jim will announce a secret location for the authors.txt file in the next days
on the ZF mailing list.


You mean the ZF mailinglist that only ZF members can join?

Thanks for the pointers so far!

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

On 3/1/13 2:49 PM, Stephan Richter wrote:

On Friday, March 01, 2013 02:37:34 PM Jan-Wijbrand Kolman wrote:

I do see someone just created an empty grokcore.component repository on
github (thanks whoever did that! :-)  )


It is actually fully converted. :-)


LOL - cool!


I am going to adjust my script to allow mutliple conversions at once. I will
take care of your list.


Really?! Thanks!!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "procedures" for moving package to github and porting to Python 3

[Jan-Wijbrand Kolman]

On 3/1/13 5:29 PM, Stephan Richter wrote:

On Friday, March 01, 2013 02:37:34 PM Jan-Wijbrand Kolman wrote:

 megrok.menu


It's done now, but it lost its 0.1 tag due to a conversion issue.


Great! And thanks again!


regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] request for more package migrations to github

[Jan-Wijbrand Kolman]

Hi,

Stephan, may I kindly request a few more package migrations to github?

Here's the list:

groktoolkit
grokcore.errorview
grokcore.permission
grokcore.registries
grokcore.resource
grokui.admin
hurry.query
hurry.workflow
z3c.bcrypt
zc.relation
zc.relationship
zopetoolkit

Thank you *very much* in advance!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] request for more package migrations to github

[Jan-Wijbrand Kolman]

On 3/22/13 12:59 PM, Stephan Richter wrote:

On Friday, March 22, 2013 10:23:21 AM Jan-Wijbrand Kolman wrote:

zopetoolkit


Is everyone ok with me moving this? Hanno mentioned that several external
tools depend on the SVN location and the move was delayed because of that. I
think this package also does not have the traditional tags, branches, trunk
structure.


Aha, ok, sorry, I missed that part. It just struck me as odd that it 
wasn't converted yet. Do not take my word for it :-)



JW, I'll convert all other packages.


Great! Thanks!

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] github etiquette

[Jan-Wijbrand Kolman]

Hi,

I wonder if there is a formal or informal write-up of how to "nicely" 
contribute code to the repositories under the zopefoundation umbrella.


Back in the subversion days I would branch a project, amend code, write 
tests, commit this to the repository, ask for feedback on the list, and, 
when deemed acceptable, merge my changes back to the project's trunk, 
perhaps even make a release of the project.


Yesterday I wanted to add a small feature to zope.formlib and wondered 
whether I should:


1) clone the "canonical" zope.formlib repository, make a branch, do my 
work, push the changes, ask for feedback on the list and eventually 
merge the branch to the mainline.


or

2) fork the repository, make a branch in the fork, do my work, push the 
changes to my fork, and issue a pull request.


The latter is what I did, without explicitly asking for feedback. 
Luckily someone did give me feedback (thanks!) :-)


Now that I mended the pull request, should I merge the pull request 
myself? Or is the current etiquette that someone else should merge the 
pull request?


My apologies in case I missed an obvious document or reference somewhere 
that describes the way "we" should work with the zopefoundation's 
codebase...


kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] github etiquette

[Jan-Wijbrand Kolman]

On 9/17/13 12:04 PM, Jan-Wijbrand Kolman wrote:
snip

2) fork the repository, make a branch in the fork, do my work, push the
changes to my fork, and issue a pull request.

The latter is what I did, without explicitly asking for feedback.
Luckily someone did give me feedback (thanks!) :-)

Now that I mended the pull request, should I merge the pull request
myself? Or is the current etiquette that someone else should merge the
pull request?


This is what I did just now.
Kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] github etiquette

[Jan-Wijbrand Kolman]

On 9/17/13 1:00 PM, Marius Gedminas wrote:

On Tue, Sep 17, 2013 at 12:04:04PM +0200, Jan-Wijbrand Kolman wrote:

I wonder if there is a formal or informal write-up of how to
"nicely" contribute code to the repositories under the
zopefoundation umbrella.


I don't think so.  I'd like to see one.


I think we're writing it Right Now :-)

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] github etiquette

[Jan-Wijbrand Kolman]

On 9/17/13 1:47 PM, Jim Fulton wrote:

I strongly prefer that the reviewer do the merge.

I'd also really like reviewers to take their responsibility
seriously, making comments and suggestions where appropriate.

Software review, done well, improves the software, and, more
importantly, improves the developers.


I agree - I know I get better from recieving feedback :-)

Is this "reviewer role" something someone takes upon himself? I mean, if 
I see a pull request for a code base that I know, I could review the 
request?


Or do we acknowledge a group of people that generally do reviews (again 
formally of informally, I don't mind, I'm not looking for "official 
procedures")?


In any case, a second pair of eyes before merging is very helpful!

regards, jw

p.s. Another thing I noticed: some of the discussion about changes and 
patches and fixes now shift from the mailinglist to github. This is 
fine, I guess.


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] github etiquette

[Jan-Wijbrand Kolman]

On 9/17/13 3:32 PM, Jim Fulton wrote:

On Tue, Sep 17, 2013 at 8:32 AM, Jan-Wijbrand Kolman

Is this "reviewer role" something someone takes upon himself? I mean, if I
see a pull request for a code base that I know, I could review the request?


These are good questions.  I probably don't have satisfying answers.

The short answer is that I think people who contribute to a project
should view review as one of their duties.  For better or worse, this is
somewhat informal.

If you don't get a review in a timely manner, try posting to the
appropriate mailing list to request a review.


Works for me :-)
regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] (optional) CSRF protection in zope.formlib

[Jan-Wijbrand Kolman]

Hi,

I've been working on CSRF protection for zope.formlib.

I have a "csrfprotection" branch in my zope.formlib fork on github. The 
changes against the current zope.formlib mainline can be found here:


https://github.com/janwijbrand/zope.formlib/compare/csrfprotection

When creating form components based on zope.formlib.form.FormBase, one 
can enable this protection just by setting the attribute ``protected`` 
to True on the component.


This implementation is based on the following assumptions:

* We do not want to keep server-side state(!)

* An "attacker" that attempts CSRF cannot get to information stored in 
cookies that are meant for the domain of the (forged) request.


* The token stored in the cookie is sufficiently random and long, to be 
practically "unguessable" by the attacker.


* The form submit is deemed valid as long as the token in the cookie is 
identical to a hidden input value that is part of the form submit.


My questions:

* Do you find this feature useful enough to be, in principle, included 
in zope.formlib?


* I'd like to kindly request someone to review my branch and provide 
feedback.


The included test cases describe a few more questions and concerns about 
this implementation.


Thank you in advance!

kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (optional) CSRF protection in zope.formlib

[Jan-Wijbrand Kolman]

On 9/18/13 5:26 PM, Leonardo Rochael Almeida wrote:

+1 for implementing convenient CSRF.

I wonder if you could make your implementation more orthogonal by
implementing a CSRF "field/widget", and make your `protected` attribute
simply trigger the inclusion of this field implicitly.

This way you wouldn't need to change the `*pageform.pt
` templates like you do now, and
`setupToken()`/`checkToken()` would move to the widget code.


I've considered and experimented with that approach. However, as soon as 
you do more complex things with setting up fields in your own form 
component, things potentially get hairy.


Furthermore, the form machinery tries to get values from the context 
object (in edit forms for example), for each field and tries to set 
values for this field on the context object when handling the submit. 
This would make handling this field special in way I didn't like.


But yes, the compromise in my implementation is, that you need to render 
the hidden input field "yourself" if you overwrite the default templates 
- and you most probably do.


For example, grok.formlib does bring its own "default" templates for 
forms. I'd need to update that package in case this implementation is 
accepted and lands.


regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (optional) CSRF protection in zope.formlib

[Jan-Wijbrand Kolman]

On 9/18/13 4:41 PM, Jan-Wijbrand Kolman wrote:

I've been working on CSRF protection for zope.formlib.


Anyone else interested in this feature?

We made an internal release of zope.formlib with this functionality and 
so far we found no issues in using it in production.


After updating zope.formlib's tests to also run on Python 3, I could 
merge this feature soon. Unless of course, someone objects :-)


kind regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release

[Jan-Wijbrand Kolman]

Christian Theune  wrote:
 
> On 03/29/2010 04:08 PM, Christian Theune wrote:
>> Hi everyone,
>>
>> on the way towards a ZTK 1.0 release we first looked for a single
>> volunteer release manager who would drive the process.
>>
>> As no one stepped up and no (serious) nominations were presented the
>> discussion went back to the drawing board and the plan was changed a
>> bit: we'd like to go with a (small) team of representatives from the
>> large ZTK consumers, namely: Zope 2, grok, and BlueBream.
> 
> We're still missing someone from grok and I just send a reminder on 

> their list. So I'm going back to hibernation on this topic for now.

You can enlist me as representative for Grok. Knowing of course that I 
can count on the grok-dev list's help.

regards and thanks for coordinating this.
regards,
jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] zope.password SSHAPasswordManager cannot handle unicode?

[Jan-Wijbrand Kolman]

Hi,

When I define a principal in my site.zcml and have it use the 
SSHAPasswordManager, I cannot login as a "TypeError: character mapping 
must return integer, None or unicode" is raised in the checkPassword() 
methid. It took me quite a while to figure out what was going on...

The site.zcml contains the encoded password for the principal that will 
be "contained" in the global principalregistry. When trying to login, 
the encoded password is taken from the principal object created from the 
information in site.zcml, and it makes sense that the encoded password 
will be an unicode string.

However the checkPassword() method of the SSHAPasswordManager cannot 
handle unicode or, more specifically, it will call 
base64.urlsafe_b64decode() on it that cannot handle unicode strings (or 
at least not in this case).

I my assesment is correct, then I must conclude no one is using the 
SSHAPasswordManager? But maybe there's something I don't understand 
about what is going wrong here...

Anyway, I guess I could fix this by have the encoded password encoded to 
ascii first before passing it to uurlsafe_b64decode. I think this would 
be safe, as the encoded password would not contain non-ascii characters 
anyway, right?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] pypi access for zope.app.authentication and zope.password

[Jan-Wijbrand Kolman]

Hello,

Could someone grant me pypi access to zope.app.authentication and 
zope.password?

My pypi username is "jw".


For compatibility reasons the upcoming Grok-1.0.x bugfix release cannot 
jump to a newer zope.app.authentication version, but I'd still like to 
add support for the SSHA password manager.

My plan is to backport the SSHA password manager to the 
zope.app.authentication 3.4 branch and make a 3.4.5 release (I realize 
this is not really a bugfix, but adding features to a x.y.Z release but 
I think (hope) that's ok for now).

Coincidentally I found a bug[1] in the SSHA password manager that I'd 
like to fix and release to make this pw manager actually useful. Could 
someone grant me pypi access for this package too?

Unless there're objections of course...

thanks and regards,
jw

[1] http://permalink.gmane.org/gmane.comp.web.zope.devel/24473

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] pypi access for zope.password Was: pypi access for zope.app.authentication and zope.password

[Jan-Wijbrand Kolman]

On 5/26/10 08:46 , Stephan Richter wrote:
> On Wednesday, May 26, 2010, Jan-Wijbrand Kolman wrote:
>> Could someone grant me pypi access to zope.app.authentication and
>> zope.password?
>
> Done.

Thanks.

However, I see "myself" in the list of package owners for 
zope.app.authentication now, but not for zope.password.

Could someone please grant me (username "jw") access to zope.password as 
well? Thanks in advance!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] pypi access for zope.password Was: pypi access for zope.app.authentication and zope.password

[Jan-Wijbrand Kolman]

On 5/27/10 8:12 AM, Christian Theune wrote:
>> Could someone please grant me (username "jw") access to zope.password as
>> well? Thanks in advance!
>
> According to PyPI jw has Owner privileges already (by now).

Uli granted me access, but his reply to me about it didn't make it to 
the list somehow. Sorry for the confusion and thanks!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Help updating the copyright attributions

[Jan-Wijbrand Kolman]

On 6/2/10 15:11 , Christian Theune wrote:
> So, I'm the first one to step up to do a hundred of them until Friday
> 2010-06-11. Who else is joining me?

I'll take a batch of ten per day until 2010-06-11.

Can I just pick from the list, or will you (or someone) hand out a batch?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Help updating the copyright attributions

[Jan-Wijbrand Kolman]

On 6/2/10 15:11 , Christian Theune wrote:
> Hi,
>
> the ZF needs to finish updating the copyright attributions to state that
> the Zope code now belongs to the foundation.
>
> I've prepared some scripts to help with monitoring which packages need
> to be updated and also a helper to update most cases.

Can you point me to these scripts?
regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Help updating the copyright attributions

[Jan-Wijbrand Kolman]

Hi,

What should I do with a package such as lovely.memcached where the 
copyright is currently attributed to "Lovely Systems and Contributors"?

Just apply the fix script?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Help updating the copyright attributions

[Jan-Wijbrand Kolman]

Hi,

Another one I'm not sure about:

   jquery.javascript

The zope.repositorypolicy readme instructs me to remove the files that 
are copyright to a non-committer. So in this case I should remove the 
whole 'js' directory from the package I guess?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Help updating the copyright attributions

[Jan-Wijbrand Kolman]

On 6/3/10 8:40 AM, Christian Theune wrote:
> On 06/02/2010 05:19 PM, Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jan-Wijbrand Kolman wrote:
>>> On 6/2/10 15:11 , Christian Theune wrote:
>>>> Hi,
>>>>
>>>> the ZF needs to finish updating the copyright attributions to state that
>>>> the Zope code now belongs to the foundation.
>>>>
>>>> I've prepared some scripts to help with monitoring which packages need
>>>> to be updated and also a helper to update most cases.
>>>
>>> Can you point me to these scripts?
>>
>>$ svn co svn+ssh://svn.zope.org/repos/main/zope.repositorypolicy/trunk\
>>  ~/projects/Zope/zrp
>>$ cd zrp
>>$ /opt/Python-2.6.5/bin/python bootstrap.py&&   bin/buildout
>>$ cd /path/to/other/project
>>$ ~/projects/Zope/zrp/bin/zope-org-check-project
>>...
>>$ ~/projects/Zope/zrp/bin/zope-org-fix-project
>>...
>>$ ~/projects/Zope/zrp/bin/zope-org-check-project
>>(should be empty)
>>$ bin/test -v --all
>>$ svn add LICENSE.txt COPYRIGHT.txt
>>$ svn commit -m "Conform to repository policy."
>
> How do you deal with packages that have broken tests due to broken
> dependencies?

I had z3c.recipe.paster with failing tests. These failed both before and 
after the copyright-fix. So, assumed I could go ahead with the copyright 
fix itself.

I do want to help out on the important copyright fixing, but I do not 
have the time right now to also fix each of the packages that I come across.

Maybe we could/should make note of the broken packages somewhere.

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Copyright update for z3c.ajax: no buildout, no headers

[Jan-Wijbrand Kolman]

On 6/3/10 8:20 AM, Christian Theune wrote:
> Hi,
>
> I just fixed up z3c.ajax and it has a quirk that the check doesn't know
> about:
>
> If a file doesn't contain any copyright attribution header, it ignores
> that file.
>
> In this case, z3c.ajax has no headers at all. no setup.py. no buildout.
>
> I added the missing license and copyright files to silence the check but
> I'm relatively sure there's an edge case here.
>
> Thoughts?

Any ideas yet on situations like these?

I found several packages now that do not contain any copyright headers 
in the python modules, or, sometimes they do in the package itself, but 
not in the package's test modules.

I decided to just go ahead for now silencing the check, my reasoning 
being: if the copyright-checkscript is updated at some point in time to 
also check for copyright-less modules, we automatically will have list 
again of project that need fixing in that regard.

OK?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] 1.4.4 bugfix release for zc.catalog

[Jan-Wijbrand Kolman]

Hi,

Grok would be greatly helped with a 1.4.4 bugfix release of zc.catalog. 
The fix we want is already implemented, we just need a release.

Is someone willing to do that? (or, would allow me to do it by granting 
pypi right for the package? My pypi username is jw).

kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Zope Toolkit - 1.0a1 release

[Jan-Wijbrand Kolman]

On 6/30/10 21:47 PM, Hanno Schlichting wrote:
> To use the ZTK release, you can use:
>
> [buildout]
> extends =
>  http://download.zope.org/zopetoolkit/index/1.0a1/ztk-versions.cfg
>  http://download.zope.org/zopetoolkit/index/1.0a1/zopeapp-versions.cfg
>
> This first release focuses on getting something out and defining the
> actual technical outcome of a release. Currently the release outcome
> is tailored to the needs of the three frameworks.

Grok's groktoolkit now extends from this 1.0a1 release. After today's 
zc.catlog bugfix release, Grok is using the ZTK now without any issues.

Thanks Hanno!

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Toolkit - 1.0a3 release

[Jan-Wijbrand Kolman]

Hello.

On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the 1.0a3 alpha release of the Zope Toolkit.

You can read more about the release at
http://docs.zope.org/zopetoolkit/releases/overview-1.0a3.html. The
first ZTK release supports all of Python 2.4, 2.5 and 2.6.

To use the ZTK release, you can use:

[buildout]
extends =
 http://download.zope.org/zopetoolkit/index/1.0a3/ztk-versions.cfg
 http://download.zope.org/zopetoolkit/index/1.0a3/zopeapp-versions.cfg

This release focuses on cleaning up the ztk and zopeapp package lists by 
deprecating packages that are not used by any of the frameworks that use 
the ZTK.

The release team is currently discussing the further roadmap to a 1.0
final release and has some open discussion points to what remains to
be done.

Specifically the release team would like to have the ZTK tests pass on 
the Windows platform, where currently there are still quite a number of 
failures. We'd like to encourage developers that use the Windows 
platform on a regular basis to help us fixing these tests.

We post our meeting notes at
http://docs.zope.org/zopetoolkit/releaseteam/index.html. Feel free to
start discussing with us on this mailing list.

Kind regards,
Jan-Wijbrand Kolman

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] z3c.recipe.i18n

[Jan-Wijbrand Kolman]

Hi,

This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The 
recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to 
release this merge as 0.8.0 as this make it possible to move grok and 
the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful 
in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point.

Unless there are objections of course :)

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

Hi,

Today I fixed a small bug in zc.catalog (the ftesting.zcml depended on a 
permission name that has been removed from zope.dublincore). This made 
me realize that zc.catalog contains ZMI code in the browser subpackage.

Are people still using this ZMI code from zc.catalog? Would it be an 
idea to move the ZMI code out of the package (a bit similar to how 
various zope.app.* package have been refactored)? It would make 
maintaining this package in respect to the ZTK easier.

Kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.recipe.i18n

[Jan-Wijbrand Kolman]

On 10/6/10 9:53 AM, yuppie wrote:
> Jan-Wijbrand Kolman wrote:
>> This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The
>> recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to
>> release this merge as 0.8.0 as this make it possible to move grok and
>> the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful
>> in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point.
>>
>> Unless there are objections of course :)
>
> +1
>
> But could you please make it more explicit that 0.8.0 drops support for
> zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe
> install_requires should specify the new requirement explicitly.

Yes, agreed.
regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.recipe.compattest buildout 1.5/1.4 compatibility

[Jan-Wijbrand Kolman]

On 10/6/10 12:49 PM, Wolfgang Schnerring wrote:
> * Jan-Jaap Driessen  [2010-10-05 18:09]:
>> Version 0.12.2 of z3c.recipe.compattest is not compatible with recent
>> versions of it's dependencies zc.buildout (v1.5.1), zc.recipe.egg
>> (v1.3.2) and z3c.recipe.scripts. I fixed this in revision 117253.
>> Is it OK with you to drop compatibility with zc.buildout versions<
>> 1.5 in the next release of z3c.recipe.compattest?
>
> I'm a little confused what's going on here. Could you explain this with
> a bit more details?
>
> I think my main questions are
> - Where and when, exactly, did which API change (it's related to recipe
>options AFAICT from the diff)
> - What does this have to do with buildout 1.5?
> - Is it a) really the case and b) intentional that buildout 1.5 breaks
>compatibility with 1.4? (Thus, can't this be avoided, possibly by
>fixing buildout 1.5?)
>
> I'm all for moving forward, but I don't really understand why the
> 1.5-update should cause such compatibility breakage.

I think in this particular case z3c.recipe.compattest relied on 
zc.buildout internals that now have have changed. So, no, I do not think 
it really is an API change and as such it is not intentional breakage 
nor something that __should__ be fixed in buildout.

Ideally, z3c.recipe.compattest would be fixed in such a way that is does 
make use of official buildout APIs.

Still there's the case that quite some recipes need to be updated to 
zc.buildout 1.5.x if they want to use its new features ("system python 
support"). Grok would really like to (easing beginners-installation for 
example). That's why we try to fix this recipes.

BTW, I discussed updating the z3c.recipe.i18n for similar reasons - to 
support newer buildout features - in a separate thread. There people 
seemed to be +1 on releasing a recipe that declares its minimal buildout 
version requirement to be >= 1.5.1. Would you say that that situation is 
similar to this?

Thanks for your feedback.
regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.recipe.i18n

[Jan-Wijbrand Kolman]

On 10/6/10 10:27 AM, Jan-Wijbrand Kolman wrote:
> On 10/6/10 9:53 AM, yuppie wrote:
>> Jan-Wijbrand Kolman wrote:
>>> This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The
>>> recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to
>>> release this merge as 0.8.0 as this make it possible to move grok and
>>> the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful
>>> in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point.
>>>
>>> Unless there are objections of course :)
>>
>> +1
>>
>> But could you please make it more explicit that 0.8.0 drops support for
>> zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe
>> install_requires should specify the new requirement explicitly.
>
> Yes, agreed.

Released as 0.80.
regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] z3c.recipe.compattest buildout 1.5/1.4 compatibility

[Jan-Wijbrand Kolman]

On 10/7/10 10:20 AM, Wolfgang Schnerring wrote:
> * Jan-Wijbrand Kolman  [2010-10-06 13:39]:
>> BTW, I discussed updating the z3c.recipe.i18n for similar reasons - to
>> support newer buildout features - in a separate thread. There people
>> seemed to be +1 on releasing a recipe that declares its minimal buildout
>> version requirement to be>= 1.5.1. Would you say that that situation is
>> similar to this?
>
> Yes, I agree, that makes sense, so +1 from me here.

Released as 0.13. Thanks for the feedback.
regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] wiki.zope.org / download.zope.org down?

[Jan-Wijbrand Kolman]

Hi,

As it seems wiki.zope.org is down, as is download.zope.org. But probably 
this is already known..? Is there anything I can do to help getting the 
machine(s) back up?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

On 10/6/10 08:08 , Michael Howitz wrote:
> Am 05.10.2010 um 20:21 schrieb Jan-Wijbrand Kolman:
>> Today I fixed a small bug in zc.catalog (the ftesting.zcml depended
>> on a permission name that has been removed from zope.dublincore).
>
> Actually the permission has been renamed (from zope.app.dublincore to
> zope.dublincore)  to get rid of the "app" part in its name.

If I would be pedantic here I'd say there is no such thing as renaming a 
permission. When the old name is gone, it is gone. There's no mechanism 
similar to the BBB imports for the permission ids.

>> This made me realize that zc.catalog contains ZMI code in the
>> browser subpackage.
>>
>> Are people still using this ZMI code from zc.catalog? Would it be
>> an idea to move the ZMI code out of the package (a bit similar to
>> how various zope.app.* package have been refactored)? It would
>> make maintaining this package in respect to the ZTK easier.
>
> zc.catalog has only test dependencies on zope.app.* packages. So you
> do not install these dependencies when using zc.calalog as a
> library. The zope.app.* dependencies might need a bit polishing. But
> I do not see a big win moving the browser part into a separate
> package. Especially as zc.catalog should depend on this new package
> for backward compatibility reasons (at least for a while).

Actually, it is more than just a test dependency. The toplevel 
configure.zcml conditionally configures the browser subpackage whenever 
zope.app.form is available. This zope.app.form conditional is not even 
"enough", as sometimes you can still have zope.app.form on your path, 
but zcml directives like addMenuItem and editForm used in 
zc.catalog.browser's configure.zcml might not have been configured.

I could imagine we change zc.catalog so that the toplevel configure.zcml 
never includes the browser subpackage's configure.zcml and people that 
need the ZMI code, need to include the zc.catalog.browser subpackage 
themselves. This would still leave the test dependency (which is 
annoying but alas), but at least make the zc.catalog easier to reuse.

regards,
jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

On 10/13/10 13:16 , Michael Howitz wrote:
> Am 13.10.2010 um 10:02 schrieb Jan-Wijbrand Kolman:
>> If I would be pedantic here I'd say there is no such thing as
>> renaming a permission. When the old name is gone, it is gone.
>> There's no mechanism similar to the BBB imports for the permission
>> ids.
>
> Not pedantic enough as there is a mechanism to rename a permission,
> see http://pypi.python.org/pypi/zope.dublincore/3.8.0#id3

Ah! Never to late to learn something - I didn't know that!

>> I could imagine we change zc.catalog so that the toplevel
>> configure.zcml never includes the browser subpackage's
>> configure.zcml and people that need the ZMI code, need to include
>> the zc.catalog.browser subpackage themselves. This would still
>> leave the test dependency (which is annoying but alas), but at
>> least make the zc.catalog easier to reuse.
>
> I'm fine with these suggestions but I'd suggest a new additional
> "browser" extra, which declares the dependencies of the browser
> subpackage.

Good idea. This would improve the testing situation. That would 
definitely help the Grok Toolkit, as it could then run the "normal" 
tests in the context of the toolkit, without pulling in the dependencies 
of the browser tests.

kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

On 10/13/10 13:42 , Jan-Wijbrand Kolman wrote:
> Good idea. This would improve the testing situation. That would
> definitely help the Grok Toolkit, as it could then run the "normal"
> tests in the context of the toolkit, without pulling in the dependencies
> of the browser tests.

Ah, no it wouldn't help there, as the testrunner would find the tests in 
the browser subpackage and it would try to run them regardless.

Then there's no real need for a browser extra, as the browser subpackage 
does not really have any code (only registrations). Or maybe you meant 
something different?

regards, jw


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Moving concrete IAuthenticatorPlugin implementations to zope.pluggableauth

[Jan-Wijbrand Kolman]

Hi,

A while ago zope.pluggable split off reusable components from 
zope.app.authentication. The concrete IAuthenticatorPlugin 
implementations (principalfolder and groupfolder) however, were left in 
zope.app.authentication.

I think it makes sense to move these IAuthenticatorPlugin 
implementations to zope.pluggableauth.plugins as well, leaving backwards 
compatibility imports and the browser code in zope.app.authentication.

For both packages I created branches [1][2] for working on this. I moved 
the components and made sure the tests pass again.

If there're no objections I'd like to merge these branches to the 
respective trunks and eventually release zope.pluggableauth 1.1.0 and 
zope.app.authentication 3.9.0.

kind regards, jw

[1] 
http://svn.zope.org/zope.pluggableauth/branches/jw-authenticator-plugins/

[2] 
http://svn.zope.org/zope.app.authentication/branches/jw-move-authenticator-plugins/

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Toolkit 1.0 release

[Jan-Wijbrand Kolman]

Hello.

On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the release of Zope Toolkit version 1.0!

You can read more about the release at
http://docs.zope.org/zopetoolkit/releases/overview-1.0.html. The
first ZTK release supports all of Python 2.4, 2.5 and 2.6.

To use the ZTK release, you can use:

[buildout]
extends =
http://download.zope.org/zopetoolkit/index/1.0/ztk-versions.cfg
http://download.zope.org/zopetoolkit/index/1.0/zopeapp-versions.cfg

This release focuses on cleaning up the ztk and zopeapp package lists
by deprecating packages that are not used by any of the frameworks
that use the ZTK. It should provide a stable set of libraries that are 
known to work well together and for the frameworks to expand on.

We post our meeting notes at
http://docs.zope.org/zopetoolkit/releaseteam/index.html. Feel free to
start discussing with us on this mailing list.

Kind regards,
Jan-Wijbrand Kolman

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

Hi Michael and Marius,

Thanks for the feedback and suggestions! This is what I did:

On 10/13/10 15:37 , Michael Howitz wrote:
> Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman:
>> Then there's no real need for a browser extra, as the browser
>> subpackage does not really have any code (only registrations). Or
>> maybe you meant something different?
>
> When someone wants to use the browser package he could use the
> "browser" extra to get all the packages needed for the ZCML
> registrations successfully load. Otherwise he has to find out himself
> where the ZCML directives are declared.

I created two extra_requires: a browser and a test_browser. The first 
lists the dependencies for the browser subpackage to work. The second 
for the corresponding tests to run.

On 10/13/10 14:42 , Marius Gedminas wrote:
> On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote:
>>> Ah, no it wouldn't help there, as the testrunner would find the
>>> tests in the browser subpackage and it would try to run them
>>> regardless.
> You could always conditionally disable them: in each test*.py file
> have
>
> def test_suite(): suite = unittest.TestSuite() if some condition:
> suite.addTest(unittest.makeSuite(...))
> suite.addTest(doctest.DocTestSuite(...))
> suite.addTest(doctest.DocFileSuite(...)) return suite

I also made the tests.py in the browser subpackage only add tests to the 
test suite whenever the test_browser dependencies indeed are available. 
This fixes the situation where a test runner (in my case the test runner 
of the grok toolkit) finds these tests and would try to run them.

The CHANGES.txt contains instructions on how to enable the ZMI views for 
your project in case you need them.

I propose to release this as 1.5.0, which would be a major version 
release that would indicate: "Watch out, potentially backwards 
incompatible changes ahead!".

Right?

Thanks again for your feedback!

kind regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Moving concrete IAuthenticatorPlugin implementations to zope.pluggableauth

[Jan-Wijbrand Kolman]

On 10/13/10 18:56 , Michael Howitz wrote:
> Am 13.10.2010 um 16:05 schrieb Jan-Wijbrand Kolman:
>
>> Hi,
>>
>> A while ago zope.pluggable split off reusable components from
>> zope.app.authentication. The concrete IAuthenticatorPlugin
>> implementations (principalfolder and groupfolder) however, were left in
>> zope.app.authentication.
>>
>> I think it makes sense to move these IAuthenticatorPlugin
>> implementations to zope.pluggableauth.plugins as well, leaving backwards
>> compatibility imports and the browser code in zope.app.authentication.
>>
>> For both packages I created branches [1][2] for working on this. I moved
>> the components and made sure the tests pass again.
>>
>> If there're no objections I'd like to merge these branches to the
>> respective trunks and eventually release zope.pluggableauth 1.1.0 and
>> zope.app.authentication 3.9.0.
>
> +1

zope.pluggableauth 1.1 and zope.app.authentication 3.9.0 have been 
released. Thank you for your feedback.

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] (re)moving browser subpackage from zc.catalog?

[Jan-Wijbrand Kolman]

On 10/18/10 21:16 PM, Michael Howitz wrote:
> Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman:
>> I propose to release this as 1.5.0, which would be a major version
>> release that would indicate: "Watch out, potentially backwards
>> incompatible changes ahead!".
>>
>> Right?
>
> +1 looks nice.

Done. Thanks.
regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] SVN: zopetoolkit/doc/source/releaseteam/ minutes of ztk releaseteam meeting 11/09

[Jan-Wijbrand Kolman]

On 11/18/10 16:50 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/18/2010 05:19 AM, Wichert Akkerman wrote:
>> On 11/18/10 11:16 , Jan-Wijbrand Kolman wrote:
>>> +The ZTK would like to use distribute by default.
>
>> Is the distribute project still alive? The reason I ask is that my
>> recent experience is that bugs reported in setuptools are fixed very
>> quickly, while there is no response from the distribute team.
>
> It does look as though development velocity on 'distribute' has slowed
> to a pace quite comparable to setuptools, with setuptools having the
> more recent release.  The two trackers are at:
>
>   
> http://bitbucket.org/tarek/distribute/issues?status=open&status=new&kind=bug&sort=id
>
>   http://bugs.python.org/setuptools/
>
> The bitbucket UI doesn't show recency of issue activity, which would
> make the two easier to compare.
>
> I'm -1 on preferring 'distribute' in any overt way in the ZTK.  Folks
> who want it can already use it when bootstrapping a buildout::

I'll make sure this is put back on the ztk release team agenda.

Note though that there was no intention to introduce "creeping" 
dependencies on distribute other than preferring it over setuptools. I 
guess we had the idea distribute was still all the rage.

The Grok project also got a few reports of strange, hard to reproduce 
installation problems (shutil not importable in some weird way for 
example), when people were using setuptools (in combination with a 
virtualenv, and zc.buildout 1.5.2) that were gone when they tried with 
the distribute option.

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path

[Jan-Wijbrand Kolman]

On 11/26/10 8:37 AM, Michael Howitz wrote:
> currently the ZTK tests on the trunk do not run successfully in a
> virtualenv.

> But reverting this change does not help to get the tests of
> z3c.recipe.compattest itself running again. There are the same errors
> like before.
>
> Is it intensional that ZTK tests fail in virtualenv? What needs be
> done to get the tests running again in virtualenv?

I don't think this was intentional. Then again, I guess it __was__ the 
intention to make use of the system-python-path-isolation-features in 
zc.buildout. Personally, I'm not sure where to start fixing this, help 
and insights appreciated...

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [Checkins] SVN: z3c.recipe.compattest/trunk/src/z3c/recipe/compattest/runner.py Don't import site on initialization, as this mitigates the buildout 1.5 way of setting sys.path

[Jan-Wijbrand Kolman]

On 11/26/10 10:49 AM, Jan-Wijbrand Kolman wrote:
> On 11/26/10 8:37 AM, Michael Howitz wrote:
>> currently the ZTK tests on the trunk do not run successfully in a
>> virtualenv.
> 
>> But reverting this change does not help to get the tests of
>> z3c.recipe.compattest itself running again. There are the same errors
>> like before.
>>
>> Is it intensional that ZTK tests fail in virtualenv? What needs be
>> done to get the tests running again in virtualenv?
>
> I don't think this was intentional. Then again, I guess it __was__ the
> intention to make use of the system-python-path-isolation-features in
> zc.buildout. Personally, I'm not sure where to start fixing this, help
> and insights appreciated...

Hmmm, maybe this has been completely obvious to others, but I guess it 
really boils down to: https://bugs.launchpad.net/virtualenv/+bug/572545 
where -S is broken in virtualenvs.

Grok's grokproject tool has exactly the same problems, where it doesn't 
work anymore in a virtualenv *and* we're using -S when calling a newly 
created project's bootstrap.py.

regards,jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] plans for a ZTK-1.1 release

[Jan-Wijbrand Kolman]

Hi,

The ZTK-releaseteam is making plans for a ZTK-1.1 release. We aim for a 
release next week. Except for an updated versions list [1], other 
significant changes will be:

* dropping python-2.4 support
* gaining python-2.7 support
* more deprecated zope.app.* packages [2]

We welcome questions, comments or suggestions regarding this plan!

Kind regards,
jw


[1] http://svn.zope.org/zopetoolkit/trunk/ztk-versions.cfg
[2] http://svn.zope.org/zopetoolkit/trunk/zopeapp.cfg

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Toolkit 1.1 released

[Jan-Wijbrand Kolman]

Hi.

On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the release of the Zope Toolkit 1.1!

To use the new release, you can use:

[buildout]
extends =
   http://download.zope.org/zopetoolkit/index/1.1/ztk-versions.cfg
   http://download.zope.org/zopetoolkit/index/1.1/zopeapp-versions.cfg

There's a bit of high level change overview available at
http://docs.zope.org/zopetoolkit/releases/overview-1.1.html

Kind regards,
Jan-Wijbrand Kolman


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] zope.pluggableauth and "camefrom" information in login form not an absolute URL

[Jan-Wijbrand Kolman]

Hi,

The SessionCredentialsPlugin will redirect to a login form whenever a 
user needs to be authenticated. The URL to this login form will have a 
"camefrom" query string, where the "camefrom" is the path-information to 
the originally requested view.

When the credentials provided by the user are correct, the login form 
will use the camefrom information to redirect back to that original view.

Ideally (a.k.a. according to the HTTP spec.), the camefrom should be an 
absolute URL, not just a path like the SessionCredentialsPlugin now does.

I'd like to fix and release zope.pluggableauth with the following patch 
applied - unless of course there's compelling reasons not to do this:

--- trunk/src/zope/pluggableauth/plugins/session.py 2011-02-07 
10:33:25.643791415 +0100
+++ 
branches/janjaapdriessen-camefrom-fix/src/zope/pluggableauth/plugins/session.py 
2011-02-07 10:40:12.301790203 +0100
@@ -308,7 +308,7 @@
  # Better to add the query string, if present
  query = request.get('QUERY_STRING')

-camefrom = '/'.join([request.getURL(path_only=True)] + stack)
+camefrom = '/'.join([request.getURL()] + stack)
  if query:
  camefrom = camefrom + '?' + query
  url = '%s/@@%s?%s' % (absoluteURL(site, request),


regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.pluggableauth and "camefrom" information in login form not an absolute URL

[Jan-Wijbrand Kolman]

On 2/7/11 12:04 PM, Adam GROSZER wrote:
> Hello,
>
> I'm not sure whether you open up a security hole there.
> Imagine that someone does a
> http://yoursite.com/@@loginform.html?camefrom=http://mysite.com
> We ended up with storing the camefrom URL in a session variable.

The redirect method in the zope publisher checks whether the redirect is 
"trusted" to go to a different host. The trusted arguments is "False" by 
default. I think will catch this situation just fine. Or doesn't it?

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] zope.pluggableauth and "camefrom" information in login form not an absolute URL

[Jan-Wijbrand Kolman]

On 2/7/11 18:03 PM, Roger wrote:
> why not use the same pattern like I changed to in z3c.authenticator.
> There the camefrom request part was replaced by session handling.
>
> On the other side, I think your changes are fine since, I guess
> someone from gocept, a long time ago, fixed and protected the
> redirect method.

Ok, thanks for your feedback!

I applied the patch, added a test just to show a redirect to a 
suspicious URL will by default not work and released zope.pluggableauth 1.3

regards, jw

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

[Jan-Wijbrand Kolman]

Hi,

Not sure where to 'hook into' the discussion thread, so I'll just start 
here:

On 3/20/11 15:28 PM, Jim Fulton wrote:
> Hm, it's been a while since I've looked at grok. Some notes:
>
> - The mechanism I'm thinking of should not require *any* ZCML.

Do you mean "without having a configure.zcml trigger the scanning 
(a.k.a. grokking) process"? Or do you mean, "a mechanism that doesn't 
use configuration actions from zope.configuration"?

If there's a different way to trigger the scanning process, that would 
be mostly fine for Grok. There's a couple of things actually configured 
thru ZCML files in some of the grokcore.* packages. I think they could 
be rewritten if necessary.

ZCML files are as far as I can see not essential to Grok - they are 
surely not essential to martian (the scanning/grokking library used).

> - The mechanism shouldn't require something to "grok"/analyze the
>code.  The mechanism should be explicit. This is implied by
>"pythonic".  I remember Grok being more implicit than skimming the
>links above suggest. Perhaps Grok has has become more explicit than
>I remember.

I have the feeling the "explicit versus implicit" part of the discussion 
has been somewhat mixed with the "to scan or not to scan" part of the 
discussion.

Nothing in the martian library dictates "implicitness" as far as I can 
see. How Grok uses martian though, does have implicit, 
conventions-over-configuration design choices.

Actually, these "conventions-over-configuration" choices are regularly 
discussed within the Grok community - some people (including myself) 
would like to see Grok not doing any "guessing" of configuration 
parameters during the grokking-phase of the application at all. Others 
disagree.

As an example, there's the "megrok.strictrequire" package that, when 
included in a grok-based application, will raise grok errors when there 
are view components without an explicitly set permission requirement 
(where Grok normally would have used a conventional value).

> - I'd prefer not to rely on subclassing, but I'm not dead set against it.

For most components Grok relies on subclassing indeed. Note that 
registering global utilities, for example, can be done using 
module-level directives too, like can be done for adapters and 
subscriptions.

> - Whataever we come up with has to work with Python 3, so
>unfortunately, we can't use the syntactic trick of having a call in a
>class like::
>
>  grokcore.component.implements(IContentProvider)

Just to be sure: this is what is called "advice based syntax" or 
"in-class advice" right? Grok people call this a "directive".

Anyway, as apparently this wouldn't work in Python 3 anymore, Grok 
should come up with an alternate spelling. Actually, people have already 
suggested to start using class decorators instead of in-class 
directives. Personally, I do not see an essential cosmetic difference 
between using a class decorator or a in-class directive.

Like was said earlier in the thread: Grok had to use directives since 
there were no class decorators at that time.

And what I have seen of Pyramid and venusian, the grok directives do 
mostly what the class decorators do: they leave information on the class 
in one way or another, that later is picked up in the scanning/grokking 
phase and used for registrations.

Grok uses "grokkers" for that - "meta"-components that know how they can 
use the information left by the directives for making registrations 
(thru the zope.configuration configuration actions mechanism, which as a 
result plays nice with existing "pure zcml" registrations)

What I know of venusian/Pyramid, is that the class decorators leave 
callbacks that will do the registrations in the scanning phase. Right?

> The effort should certainly include an analysis of approaches like
> grok.  Maybe the mechanism should have the effect of enabling tools
> like grok to be implemented more cleanly.

I do not think the Grok project would be principally against this.

regards, jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

[Jan-Wijbrand Kolman]

On 3/20/11 16:12 PM, Wichert Akkerman wrote:
>>> Both Grok and Pyramid (or martian and venusian really) do a scan of
>>> the code to find the registration hints.
>>
>> Pyramid only does so if you tell it to do so by using config.scan(). You
>> are not obliged to do that, and I have several pyramid projects which do
>> not do any scanning. Not doing scanning has the advantage of making
>> configuration more explicit, and it speeds application startup immensely.

Just to get this clear for me: if you're not scanning, the information 
left by the class decorators would be "inert"? So, you'd have to do the 
registrations "yourself", right?

> Let me try to argue this better. Downsides of scanning are:
>
> - it scans your tests, which can result in unexpected behaviour you
> may not expect (at least for venusian, not sure if this is true for
> martian).

Martian skips tests by default. You can tell it, at least to a certain 
extend, what to scan and what not to scan.

> - you may have some draft files in your tree that are not ready for use
> and never referenced anywhere, but a scan will still process them.

This is true.

> - scanning can take a long time, making application (re)start slow for
> non-trivial projects

At what point is an application not trivial anymore? In applications I 
build so far, startup time has not been an issue at all. But maybe my 
applications are still on the trivial-end of the spectrum ;)

> - problems in the scanning process tend to be very hard debug. If a
> view is not processed during scanning figuring out why can be
> painful, and there are little to no tools to help you. This is
> especially true for more complex scanning environments such as the
> plone/dexterity/z3cform stack; as an example I spent over an hour
> yesterday trying to figure out why a form was not picked up while
> other views in the same python file worked fine.

I think this can be true. In my experience not relying on implicitly or 
"guessed configuration parameters helps a little here. What in this 
specific example was the reason for the view not being picked up?


regards, jw




___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

[Jan-Wijbrand Kolman]

On 3/21/11 10:30 AM, Wichert Akkerman wrote:
  >>> - you may have some draft files in your tree that are not ready 
for use
>>>   and never referenced anywhere, but a scan will still process them.
>>
>> This is true.
>
> I ran into this with .html.py files generated by Chameleon as well. My
> Zope startup has lots of these:
>
> /Users/wichert/Library/eggs/zope.configuration-3.6.0-py2.6.egg/zope/configuration/config.py:605:
> UserWarning: File 'sessions.pt.pyc' has an unrecognized extension in
> directory
> '/Users/wichert/Work/syslab/euphorie/Develop/trunk/buildout/src/Euphorie/euphorie/client/templates'

I think this particular warning is not due to the scanning process 
itself, but due to the way Grok tries to associate templates to views.

It is still true though that the .pt.py files generated by chameleon 
will be scanned anyway.

regards, jw



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )