Re: [Zope-dev] Porting zope.dottedname to Python 3

2013-02-05 Thread Wolfgang Schnerring
Hello,

* Marius Gedminas mar...@gedmin.as [2013-02-05 17:56]:
 The mailing list archive contains a lot of advice.  (If this were a wiki
 page, I'd add links to the relevant emails).  What I'm trying to do
 here is to provide a concrete example of the porting pattern discovered
 by others (especially Lennart Regebro and Tres Seaver):

Thanks for the thorough writeup!

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] WebSockets API

2012-11-27 Thread Wolfgang Schnerring
Hi,

* Alex Leach albl...@york.ac.uk [2012-11-25 20:00]:
 I was wondering if anyone has implemented a WebSockets server API using the 
 zope toolkit? I've just submitted a blueprint on Launchpad 
 (https://blueprints.launchpad.net/zopetoolkit-project/+spec/websockets-api), 
 but thought it might be quicker and easier to discuss how one could do this 
 here.

I'm not too familiar with WebSocket internals, but one thing that stuck
with me is that you'll need to keep *lots* of open connections, which is
only feasible with an eventloop-based server (which zope.server, for
one, isn't).

Apart from that, I'm not sure what features remain, and where a proper
home in the ZTK world would be.

At our company we've scheduled a project to integrate WebSockets into a large
Zope3-based application for early next year, so we'll definitely will be
doing *something* in that space -- we just don't know what, yet. ;)

What functionality did you have in mind that the ZTK might grow?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · Software development
gocept gmbh  co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany
http://gocept.com · Tel +49 345 219401-0
Python, Pyramid, Plone, Zope · consulting, development, hosting, operations

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] We need to change how code ownership works.

2012-08-20 Thread Wolfgang Schnerring
* Lennart Regebro rege...@gmail.com [2012-08-19 13:01]:
 On Sun, Aug 19, 2012 at 10:30 AM, Jens Vagelpohl j...@dataflake.org wrote:
 Legally, both are disallowed unless there's some proof (written
 statement etc) from the code author that he assigns ownership of the
 patch or the contents of that pull request to the contributor who is
 doing the checkin.
 This is then, IMO a problem that we should fix. What you are in fact
 saying is that the current system are violating people's copyright
 everytime we merge a non-contributors patch. It is unfeasible to not
 merge peoples patches, and I think it is also a big problem that the
 way the ownership of the code works now inhibits the increased
 simplicity of making and merging fixes for non-core contributors.

 In other words, we have had an ownership situation which is terrible,
 and nobody seems to have realized this until now. Well, now we know.

 As such, the discussion must now shift from don't do this to how do
 we do this. Poeple want to contribute and we should not say don't do
 that, we have to figure out *how* to make it possible to do that, and
 pretty pronto as well.

Yes, please, let us try and shift the discussion from stop it right
there! to how can we make this work?.

I think this means taking seriously both sides of the story,
a) Using Github is found to be quite attractive by lots of people.
b) We need to be diligent in maintaining the chain of custody of code so
the copyright situation is kept clean.

As far as I understand it, the legal lynchpin is that using Github
(strongly) encourages merging code contributions of people that did not
sign a contributor agreement -- which is the same situation as if
someone attaches a patch file to a bug tracker ticket, but will be much
more frequent and likely to happen.

Could we, then, adopt a policy that we only merge pull requests (or
whathaveyou) from people that have signed a contributor agreement?
a) Tres, Jens: Would that work from a legal perspective?
b) Ross, Alex: Would that still yield the advantages of the distributed
source control model?

What other solutions would be possible?

Wolfgang

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


Re: [Zope-dev] RFC: release persistent as a standalone package

2012-07-02 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2012-06-30 20:02]:
 I have completed the work needed to make 'persistent' distributable
 as a standalone package.  The effort (begun almost four years ago!)
 includes the following highlights:

 I would like to release a '4.0.0' version of the package, and switch
 the ZODB trunk to pull it in as a dependency (deleting the currently
 included (older) copy of persistent).

+1, please do. This seems like a(nother! :) Good Thing(tm) to me.

Wolfgang

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


Re: [Zope-dev] RFC: proposing to merge 'tseaver-test_cleanup' branch of zope.component to trunk

2012-06-28 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2012-06-28 00:04]:
 I've done with the porting / test cleanup effort on this branch:
  svn+ssh://svn.zope.org/repos/main/zope.component/tseaver-test_cleanup
 Highlights of the changes in this branch, targeting a 4.0 release:
 - Added PyPy and Python 3.2 support (tested by tox):
 - 100% unit test coverage.

 Unless there are strong objections, I plan to merge this to the trunk
 this week, and make a 4.0.0 release.

+1 please do -- those are lots of steps in the right direction, thanks
for tackling this!

Wolfgang

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


Re: [Zope-dev] Merge proposal: zope.interface/branches/tseaver-no_2to3

2012-04-16 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2012-04-05 22:36]:
 Having merged the 'tseaver-better_unittests' branch to the zope.interface
 trunk last Friday, I now have a new branch ready for merging:

   http://svn.zope.org/zope.interface/branches/tseaver-no_2to3

 The branch excises the use of the 'lib2to3' module and associated fixers
 in favor of a compatible subset which supports Python 2.6, 2.7, 3.2,
 and PyPy 1.8.  At this point all tests pass under all four environments
 using 'python setup.py test' as well as using 'nosetests.'  Code coverage
 is at 99.9% (two edge-case lines are untested).

Woot!

However alluring the 2to3 idea might have been, it seems to me that the
single-source approach (with the six package if needed) is the only sane
way to go.

 Unless the community's consensus is against the branch, I plan to merge
 it to the zope.interface trunk by early next week.

+1, please do!

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.form/trunk/setup.py Get ready for 2.6.1 release.

2012-02-19 Thread Wolfgang Schnerring
* David Glick davidgl...@groundwire.org [2012-02-19 22:56]:
 On 2/16/12 11:55 PM, Adam GROSZER wrote:
 So you say that if I add
 entry_points={
 'zest.releaser.releaser.after_checkout': [
 'zest_pocompile = zest.pocompile.compile:compile_in_tag',
 ],
 },

 to z3c.form's setup.py fullrelease will take care of the po files?

 You'll have to experiment -- the suggestion was based on what I've heard, not
 personal experience with zest.releaser.

The entrypoint looks sound at first glance, but what I'm wondering (and
rather doubting, in fact) is whether zest.releaser includes the package
it currently is releasing to its PYTHONPATH. But yeah, as David said,
you'll probably need to fiddle around with this a little.

Wolfgang

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


Re: [Zope-dev] zope.server still used?

2011-12-19 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-12-18 03:57]:
 Is zope.server still largely used by e.g. bluebream, grok, and other
 zope 3 apps?  Or do people tend to use other WSGI servers instead?

We're using zope.server on several Zope 3 projects (that were begun
before grok or WSGI or anythin existed ;), and it's *ahem* serving us
just fine, no hiccups, no nothing, just doing its job.

(We, too, see the occasional broken pipe error in our logs like Marius
mentioned, I think that's due to requests that were aborted client-side,
thus more an annoyance than anything.)

On the other hand, we still haven't found a WSGI server we're happy with
for deployment (as opposed to development). Paster has been known to
randomly die on us (yup, I've only got anecdotes and nothing hard and
fast, sorry), and the whole area of daemon management, logging,
logrotation and so forth (not to mention buildout integration) seems not
as advanced as we've come to know. What do people use here, what are
your experiences and ideas?

Wolfgang

-- 
Wolfgang Schnerring · email/jabber: w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting, operations

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Announcement: gocept.zcapatch 1.0 released

2011-12-06 Thread Wolfgang Schnerring
* Stephan Richter stephan.rich...@gmail.com [2011-12-05 09:16]:
 On Monday, December 05, 2011 12:43:35 PM Wolfgang Schnerring wrote:
  So we decided to solve our most immediate needs (that are not taken
  care of by plone.testing's stacking solution of the global registry),
  namely temporarily altering utility/adapter/handler registrations.
 
 Why did you not just wrap the config in a z3c.basegeistry directive?

I'm afraid I don't understand how that could help in what I'd like to
do. The use case I'm concerned with looks roughly like this:

def test_client_code_that_uses_IFoo_utility_correctly(self):
fake_utility = mock.Mock()
fake_utility.underlying_method.return_value = 'canned response'
self.zca.patch_utility(fake_utility, IFoo)
client_code.perform()
fake_utility.underlying_method.assert_called_with(correct_arguments)

With the additional conditions that
- I'm probably loading configure.zcml in the layer of this test, which
defines real IFoo (and, possibly, IBar) utilities.
- The client code under test might (or might not) use IBar; either way,
I don't care, and certainly don't want to have to mock it, too, for
*this* test.
- Other tests will likewise want the real IFoo implementation.

In other words, I want to replace the utility precisely for this test,
isolated from all other tests, and isolated from the layer setup
below. plone.testing's stacking approach might help, but only as long
as only zope.component.getGlobalSiteManager() is concerned, and as
long as I'm only adding or exchanging stuff (come to think of it, I
should go and check whether I can remove things registered in
__bases__ by registering None in the stacked registry...).

As far as I can tell, z3c.baseregistry merely introduces another
registry (with __bases__ set up sensibly), so I don't think that can
help here, or can it?

Wolfgang

-- 
Wolfgang Schnerring · email/jabber: w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting, operations


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


[Zope-dev] Announcement: gocept.zcapatch 1.0 released

2011-12-05 Thread Wolfgang Schnerring
Hello,

after much discussion[1], Thomas Lotze and I tried to implement
generic copying/stacking of component registries[2], but ultimately
failed due to the same issues that Martin Aspeli had already foreseen:
For the general case there are way too many edge cases, especially
regarding persistent registries.

So we decided to solve our most immediate needs (that are not taken
care of by plone.testing's stacking solution of the global registry),
namely temporarily altering utility/adapter/handler registrations.

We've now released this effort as gocept.zcapatch[3], and look forward
to comments and further ideas about this. I also wonder whether this
might eventually get another home (plone.testing? zope.component? Or,
nowadays, zope.interface?), but that's for after trying it out in the
real world.

Wolfgang


[1] http://thread.gmane.org/gmane.comp.web.zope.devel/26469/focus=26484
[2] http://svn.zope.org/zope.component/branches/wosc-test-stacking/
http://svn.zope.org/zope.interface/branches/wosc-test-stacking/
[3] http://pypi.python.org/pypi/gocept.zcapatch

-- 
Wolfgang Schnerring · email/jabber: w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting, operations


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


Re: [Zope-dev] merge zope.configuration dictactions branch

2011-12-04 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-12-05 04:02]:
 ssh://svn.zope.org/repos/main/zope.configuration/branches/chrism-dictactions

 I want to be able to associate a new value (introspectables) with each
 ZCML configuration action

 On the zope.configuration trunk (and in all past releases), each ZCML
 action is maintained as a tuple.  The tuple can be of any length up to
 seven elements, but mustn't exceed a length of seven.

 the z.config code is much easier to understand when the action is just
 a dictionary instead of a pseudo-struct.

+1, this makes a lot of sense to me.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Supporting interworking with repository branches on github

2011-11-22 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2011-11-22 22:46]:
 On 11/22/2011 12:13 PM, Laurence Rowe wrote:
 While the Zope Foundation deliberates on version control, I think
 it's likely that development will continue using Git and Github.

 Please don't try to jump the gun on the process here [...]
 It is not appropriate for a small subset of the community to preempt
 this kind of choid: ask forgiveness rather than permission is *not*
 going to fly here, and trying to push harder only irritates folks you
 might otherwise persuade.

When reading the emails on this list about this topic, I get a strong
feeling of us vs. them. Is that really necessary?

In that light, and trying to make visible the (positive!) aspects of the
different opinions, allow me to ask:

Tres, while I realize that you also rightly raise the formal issue that
a vocal minority shouldn't surge ahead and create facts, do I understand
you correctly that the main inherent[1] issue is a legal one, concerning
proper handling of copyright etc.? Could someone explain what's at stake
here, since at least I only have a vague feeling of if something in
that area goes wrong, it could be really bad?

Laurence, do I understand you correctly that your main concern is ease
of use for development and that decentralized version control would be
preferable to a centralized one? Do you feel unduly blocked by the need
to resolve these (rather tricky) legal issues? Might a technical
solution be of use until this is resolved (git can read/write svn, can't
it)?

Wolfgang


[1] Sorry, my English is failing me. I'm looking for a word that means,
as opposed to formal.

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


Re: [Zope-dev] zope-tests - FAILED: 4, OK: 40, UNKNOWN: 2

2011-11-19 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2011-11-19 14:31]:
  [1]UNKNOWN UNKNOWN : Zope-trunk Python-2.6.6 : Linux 
  https://mail.zope.org/pipermail/zope-tests/2011-November/052856.html
  
  [2]UNKNOWN UNKNOWN : Zope-trunk-alltests Python-2.6.6 : Linux 
  https://mail.zope.org/pipermail/zope-tests/2011-November/052857.html
 
 These two are also tied to the missing zope.publisher 3.13.0 release.

Mea culpa about the missing release; I don't actually know what
happened, since I use zest.releaser, so there isn't all that much that
should go wrong, usually. And I certainly didn't notice anything was
amiss. Sorry about that. I've uploaded the release just now.
 
  [3]FAILED  ZTK 1.0dev / Python2.4.6 Linux 64bit 
  https://mail.zope.org/pipermail/zope-tests/2011-November/052845.html
 
 We need to tie ZTK 1.0dev to a backward-compatible branch of
 zope.publisher (no longer the trunk).

Ah. Right, that makes sense. 3.12.x then?
 
Wolfgang

-- 
Wolfgang Schnerring · email/jabber: w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting, operations


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


Re: [Zope-dev] zope-tests - FAILED: 5, OK: 41, UNKNOWN: 1

2011-11-17 Thread Wolfgang Schnerring
* Zope tests summarizer nore...@zope.org [2011-11-18 02:00]:
 [2]FAILED  ZTK 1.0dev / Python2.4.6 Linux 64bit
https://mail.zope.org/pipermail/zope-tests/2011-November/052798.html
 Module: zope.publisher.tests.test_testing
 
   File 
 /home/ccomb/ztk1.0dev-slave/Python2.4.6-Linux-64bit/build/src/zope.publisher/src/zope/publisher/tests/test_testing.py,
  line 33
 with zope.publisher.testing.interaction('foo'):
 ^
 SyntaxError: invalid syntax

I introduced this context manager in zope.publisher, fully aware that it
requires 2.5 at the least (which complies with the ZTK 1.1 specification
of 2.5--2.7).

Thus, I'm really confused why the builder for ZTK 1.0 is picking this up,
I've only bumped the version of zope.publisher in toolkit/trunk, nowhere
else.

Can somebody enlighten me what ZTK 1.0dev actually builds?

Thanks,
Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser release?

2011-11-02 Thread Wolfgang Schnerring
* Wolfgang Schnerring w...@gocept.com [2011-10-28 08:43]:
 * Benji York be...@benjiyork.com [2011-10-26 16:42]:
 On Wed, Oct 26, 2011 at 10:26 AM, Wolfgang Schnerring w...@gocept.com 
 wrote:
 I've added an assertion helper to zope.testbrowser that provides
 ``assertEllipsis``, which is very helpful when using Testbrowser with
 unittest.TestCase (instead of doctests).

 I'm +1 on the functionality, and -0 on the location.  This would seem
 more appropriate in a general extensions-for-unittest package (like
 http://pypi.python.org/pypi/testtools).

 Actually, when you're putting it like this, I find myself in complete 
 agreement. :-)
 I'll revert that from zope.testbrowser and probably start gocept.testing
 or somesuch instead.

And here we go:
http://pypi.python.org/pypi/gocept.testing/1.0

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser release?

2011-10-28 Thread Wolfgang Schnerring
* Benji York be...@benjiyork.com [2011-10-26 16:42]:
 On Wed, Oct 26, 2011 at 10:26 AM, Wolfgang Schnerring w...@gocept.com wrote:
 I've added an assertion helper to zope.testbrowser that provides
 ``assertEllipsis``, which is very helpful when using Testbrowser with
 unittest.TestCase (instead of doctests).

 I'm +1 on the functionality, and -0 on the location.  This would seem
 more appropriate in a general extensions-for-unittest package (like
 http://pypi.python.org/pypi/testtools).

Actually, when you're putting it like this, I find myself in complete 
agreement. :-)
I'll revert that from zope.testbrowser and probably start gocept.testing
or somesuch instead.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser release?

2011-10-26 Thread Wolfgang Schnerring
Hello,

I've added an assertion helper to zope.testbrowser that provides
``assertEllipsis``, which is very helpful when using Testbrowser with
unittest.TestCase (instead of doctests).

Some examples:

self.assertEllipsis('...bar...', 'foo bar qux')
  # - nothing happens

self.assertEllipsis('foo', 'bar')
  # - AssertionError: Differences (ndiff with -expected +actual):
   - foo
   + bar

self.assertNotEllipsis('foo', 'foo')
  # - AssertionError: Value unexpectedly matches expression 'foo'.

For convenience, if no ``actual`` value is provided,
``self.browser.contents`` is used.

I'd like to cut a release of zope.testbrowser, if nobody has any
objections against my doing so. There are also unreleased changelog
entries about handleErrors and WSGI, which look fine to me.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting


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


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-09-08 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-09-06 20:06]:
 On Tue, 2011-09-06 at 12:50 +0200, Wolfgang Schnerring wrote:
  * Chris McDonough chr...@plope.com [2011-09-01 04:27]:
   It wouldn't be the end of the world to have the global registry and the
   global API live in zope.registry, but it doesn't help Pyramid for it to
   be in there, and it probably wouldn't help anyone else either.  The
   global API (which includes getSiteManager) is really just a convenience
   feature, and splitting that global API across more than one package
   doesn't seem to make sense to me.
  
  I guess this is the central issue where we have different opinions.
  I don't consider those just convenience, but rather concept-bearing
  of their on right.
 
 Convenience and concept bearing aren't mutually exclusive. Whom
 would be served if we moved the global API to zope.registry?  Are you
 thinking that zope.registry would be some sort of fresh start for
 zope.component?  If so, is anyone willing to promote it, write new docs,
 etc?

Yes, I like the idea of a fresh start (or at least proper clean
up) quite a bit. And I'd definitely be up for writing (new)
documentation. You've set a great example in that regard with Pyramid
that is very much worth emulating for other packages.

   It also implies conditional dependencies on zope.security (in
   z.c.hooks.setSite, and other places), which are even now pretty nasty.
  But I don't see where that would come from. As far as I understand it,
  hooks.setSite wouldn't be in zope.registry.
 
 If we were to move all this stuff into zope.registry, I think we'd do
 just as well to leave zope.component as-is, but port all of its
 dependencies to Python 3.

Isn't that a little too black and white?
I find value in the idea of removing the dependencies to ZODB, ZCML
and zope.security, while leaving zope.event/zope.testing in place.

 Although that's a noble goal, I personally won't be doing that any
 time soon; I'd instead just take the code we actually from
 zope.component and put it into Pyramid itself.

I agree, porting the whole hairball is way too much, and I
definitely wouldn't want to burden you/Pyramid with that.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-09-08 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-09-08 05:21]:
 On Thu, 2011-09-08 at 09:01 +0200, Wolfgang Schnerring wrote:
  Yes, I like the idea of a fresh start (or at least proper clean
  up) quite a bit. And I'd definitely be up for writing (new)
  documentation. You've set a great example in that regard with Pyramid
  that is very much worth emulating for other packages.
 
 I'm behind the goal of cleaning up and documenting componenty things
 better, and I think those are very worthy ideas.  But I think blocking
 the proposed division while we hash out the details of what some second
 generation zope.component might be is probably not in anyone's best
 interest.  If there were some branch laying around with a proposed set
 of changes, it might be more reasonable, but there's not, and it will
 take months to create one (after discussion, planning, development,
 rehashing, etc).  The creation of a second package today that just holds
 the proposed bits doesn't prevent future innovation, AFAICT.

I guess that extracting just a little bit right now won't get in the
way of doing things properly (since that most likely means
extracting a little more and then documenting it), and I certainly
don't want to stand in the way there.

However, that means that the package currently called zope.registry
will quite likely become the future of zope.component. In that light
I'd really like to try and come up with a better name -- Jim?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-09-06 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-09-01 04:27]:
 It wouldn't be the end of the world to have the global registry and the
 global API live in zope.registry, but it doesn't help Pyramid for it to
 be in there, and it probably wouldn't help anyone else either.  The
 global API (which includes getSiteManager) is really just a convenience
 feature, and splitting that global API across more than one package
 doesn't seem to make sense to me.

I guess this is the central issue where we have different opinions.
I don't consider those just convenience, but rather concept-bearing
of their on right.

 It might make sense for the entire global API to be in zope.registry,
 but if you take global API to mean what it does now that implies
 dependencies on at least:
 
 - zope.event (zope.component.event.dispatch)
 - zope.testing (for addCleanUp of the global registry in
   z.c.globalregistry and other places)

Yep, those two would be necessary.
 
 It also implies conditional dependencies on zope.security (in
 z.c.hooks.setSite, and other places), which are even now pretty nasty.

But I don't see where that would come from. As far as I understand it,
hooks.setSite wouldn't be in zope.registry.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-09-01 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2011-08-30 09:25]:
 On Tue, Aug 30, 2011 at 2:23 AM, Wolfgang Schnerring w...@gocept.com wrote:
  My understanding is that from a client's perspective these two are
  equivalent: if you want the foo functionality for zope.component, you
  have to depend on zope.component[foo], and you import stuff from
  zope.component.foo.
 
 Except that probably many (most?) clients of zope.component don't
 bother to name the extras because they depend on the other
 dependencies anyway, for other reasons.

Yes, right, I see that now. Thanks for clarifying!

Hmm, I guess I'm going to lose if I try to argue that not naming the
extra is wrong and thus deserves no respect or compatibility
protection, am I not?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-09-01 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-08-30 03:51]:
 On Tue, 2011-08-30 at 08:47 +0200, Wolfgang Schnerring wrote:
 My interpretation of your suggestion is that maybe that zope.component
 end up as what zope.registry is now.  But I don't think preserving the
 name zope.component for this small core and spinning off everything
 else in the package into separate bits is very attractive, because
 zope.component is just a name and we can do it with a lot less churn
 and potential for bw incompat if we just rename the core bits rather
 than changing the meaning of zope.component to be just the core
 bits.

Yep, that's a fitting assessment.

I have two concerns, the more important one is to establish a clear
definition of what concepts and functionality constitute the Zope
Component Architecture (in other words, for the most part, what of
everything that currently is in zope.component does actually belong
there?) and to keep these core bits intact when we're extracting
and/or pruning.

The second one is that the established package name for the ZCA has
been zope.component, and that I'd rather keep it that way. But I guess
I'd be willing to concede that point and take up a new name, since I
agree that trying to keep it probably requires more churn and
headaches than changing it.
But I also guess I'd like the new name to be more evocative than
zope.registry. Yes, I fully realize the bikesheeding potential, and
I'm sorry (a little at least ;-), but the ZCA is so much at the core
of the Zope world I feel it deserves some consideration so as to carry
a fitting name.

By the way, while we're taking up new names and leaving
zope.component intact as bw compat, can we use that opportunity to
clean up the terminology a little? For example, class Components
should IMHO become class Registry, and getSiteManager could be
something like getCurrentRegistry.

**

To take up the what is the ZCA question again, I don't know if this
helps or confuses, but here goes: yesterday we (Thomas Lotze, Michael
Howitz and myself) brainstormed at the office whiteboard and came up
with stuff the ZCA is used for in Zope3-ish applications:

- Dependency Injection to promote inversion of control (utilities)
- Multiple dispatch to promote extensibility (adapters)
- Event handlers to promote decoupling (subscribers)
- Plain old configuration (any of the above can be bent towards that
  purpose, my favourite example being how the default view name is
  handled... ouch.)
- The notion of a context in which the application runs and that
  informs its behaviour (in Zope3 terms, the site; more on that
  below)

These seem to be quite different things, and I'm not certain they
*should* be all together in one place, but on the other hand,
extracting zope.registry as proposed seems to me to take out just
slices of each (think vertical stripes) and leave other parts of
each behind in zope.component, which seems to me the wrong way around
(horizontal stripes would be better).

 As far as I'm concerned, the ZCA global API and zope.event machinery are
 not guts; they are convenience APIs on top of the guts.  Each promotes
 the idea that there is a single registry per process, which is not
 always true (it's not in Pyramid, anyway).  I'd be a -1 on seeing these
 sorts of convenience APIs come along for the ride into the guts
 package, whatever that ends up being.

I don't think zope.component.getSiteManager() promotes a single
registry per process, but rather (although maybe just as jarring) the
concept of a current registry.

While personally I'm not so sure anymore that this is a Good
Thing(tm), I feel it is quite fundamental to how zope.component is
used and thought about. If you take this notion away, of a context in
which code runs and which provides a current registry, no more
IFoo(bar) and no more simple getUtility, but you'll have to explicitly
retrieve or pass around the registry.
(I guess Pyramid does it like that? The registry lives on the request
and that is passed around throughout the framework?)

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: proposal to split zope.configuration into ZCML and non-ZCML related packages

2011-08-31 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-08-28 21:35]:
 Pyramid doesn't actually require ZCML or zope.schema; it only uses
 the parts of zope.configuration related to actions, conflict
 resolution, and the ConfigurationMachine itself. These bits have
 proven useful outside the context of ZCML and other schema-driven
 configuration.
 
 I have tackled this issue by factoring zope.configuration into
 two pieces:
 - I have moved the bits that don't rely on ZCML or zope.schema
   into a new 'zope.configmachine' package
 - I have made zope.configuration which depends on 
   zope.configmachine in a branch:

Splitting zope.configuration into core mechanics and ZCML support
makes a lot of sense to me.

I'm not too hot about the zope.configmachine name, because it's all
mechanics and not much intention, but I realize the bikeshedding
danger here.

So, +1 from me.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-30 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2011-08-26 07:35]:
 On Fri, Aug 26, 2011 at 3:51 AM, Wolfgang Schnerring w...@gocept.com wrote:
  * Jim Fulton j...@zope.com [2011-08-25 15:24]:
   stripping zope.component to its core would be backwards incompatible now.
 
  Why? zope.component already uses extras_require to signify the various
  integration parts: [persistentregistry,security,zcml].
 
 But it still contains code to go with those dependencies. To clean
 this up, you'd have to remove that code, which would cause breakage.

I have the feeling I'm missing or overlooking something. Could you
help me find it? These are the two scenarios, as I understand them:

a) zope.component declares an extras_require foo, making it depend
on zope.foo, and also has a module zope.component.foo with integration
code in it.

b) zope.component declares an extras_require foo, making it depend
on zope.foo *and* a new package zope.component_foo (which contains the
extracted integration code). Also, zope.component has BBB imports in
zope.component.foo that point to zope.component_foo.

My understanding is that from a client's perspective these two are
equivalent: if you want the foo functionality for zope.component, you
have to depend on zope.component[foo], and you import stuff from
zope.component.foo.
 
  The current zope.component, because it came out of the Zope3 monolith,
 
 That's not right. When Zope3 was managed as a single whole,
 zope.component was far more cohesive and less tangled than it is
 now. It gained a bunch of cruft in the rush to kill
 zope.app.component when code was moved from zope.app.component was
 mistakenly moved to zope.component.

Ah, I wasn't properly aware of that part of its history. Thanks for
clarifying!

 I think treating integration with zope.event as core would be
 reasonable.

That makes sense. Event handlers certainly feel like a useful (and
widely-used) feature to me.
 
  - zope.security
  - zope.configuration
  - ZODB
  In that light, it makes a lot of sense to me to have two (or more?)
  packages, core and integration, but I'd *very* much like them to be
  named in a way that one can tell this fact from their names.
 
 Me too. I wish the destruction of zope.app.component had happened
 differently.  I'd like to have meaningful names, but I'd rather not
 incur more backwards incompatibility to get them.
 
 It's certainly valid to argue for the backward incompatibility. It's a 
 tradeoff.

I think I don't want to argue for incompatibility, but rather I am
glad that we are exploring what degrees of freedom for improvement
remain available to us while still preserving compatibility.

  What remains is the issue that zope.component *also* contains code for
  the thread-local site concept -- which doesn't feel like an integration
  with another package, but might not be considered core functionality,
  either (I'm not sure yet but I lean towards considering it core).
 
 IMO, what's core is a way to plug in component registries, not a
 particular strategy for component registries.

Do I understand you correctly that the fact that getSiteManager is
hookable should be core, but the thread-local mechanism of setSite()
should not? That seems like a very useful delimination.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-30 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-08-26 13:27]:
  So I'd like to propose to do the split the other way around: Not
  extract the core into something else and leave only a hollowed-out
  shell of integration and miscellany stuff behind, but rather tighten
  zope.component to its core and move the optional integration bits out
  of it, into separate packages.
 
 I'm -1 on redefining the meaning of zope.component.

I'm afraid I don't understand what you're saying. Could you expand on
this? What meaning is redefined to what by which proposed action(s)?

 Otoh, if the name zope.registry (or the introduction of a new
 package) is a problem, I'd suggest we move the stuff that is
 currently in zope.registry to zope.interface. zope.interface
 already contains a bunch of registry-related code; it'd make
 complete sense to me.

That's an interesting suggestion, since zope.interface contains the
bigger half of all the adapter mechanics already. (zope.interface
would gain the concept utility, an adapter from nothing, but I
wouldn't mind that, I guess.)

However, my main driving point here is coherent package boundaries,
and as said elsewhere in this thread, I think that the core of
zope.component comprises more than just the Registry class, namely the
(hookable) getSiteManager protocol and probably zope.event integration
-- and I'm not sure that all this belongs into zope.interface.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-30 Thread Wolfgang Schnerring
Hello Charlie,

* Charlie Clark charlie.cl...@clark-consulting.eu [2011-08-26 11:17]:
 Am 26.08.2011, 09:51 Uhr, schrieb Wolfgang Schnerring w...@gocept.com:
  However, what's important to me is that we try to make packages
  cohesive, and that we try to make integration between packages
  understandable.

 I think that what you suggest is too much for the moment and I think it  
 even contains the Zope 3 risk of trying to get everything right.

I fully agree that it is not feasible to do everything at once, and
that we should take small but continuous steps towards the goal.
But my aim was first and foremost to point out that the currently
proposed step is going *in the wrong direction* in my opinion.
Upon that it's a little disheartening to hear that I'm trying to do
too much.

 Tres' proposal has the not inconsiderable advantage of merging work  
 already done.

This feels a lot like the facts are already there, end of discussion
to me, and I hope you agree that this is not a reasonable argument.

 And, given that the work has come from an external if related
 project, the main aim of exposing these libraries to the wider world
 has been achieved.

That is true and I'm glad we're leaving the monolithic state it's all
of Zope or nothing behind more and more. However, to mention the goal
again (which is worth moving towards, I think), I really think we
should not split things up just so according to current mechanical
requirements, but also think about conceptual boundaries.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-30 Thread Wolfgang Schnerring
* Chris McDonough chr...@plope.com [2011-08-30 03:51]:
 If there's some solution that doesn't break bw compat but gets what
 you're after, I couldn't possibly be opposed to it.  But I don't see how
 it can happen without some backwards incompatibility, even if that
 backwards incompatibility is the requirement that a user install
 setuptools extras to get what used to come along with the core.

A. *slaps forehead*

There's my thinking mistake. Currently, the extras_require is *not*
necessary to get the integration bits, clients can depend on *only*
zope.component. That would have to change with my idea, and that's not
bw compatible. Right.

I have to think this over (at least) once more.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 219401 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-26 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2011-08-25 15:24]:
 On Thu, Aug 25, 2011 at 2:50 AM, Wolfgang Schnerring w...@gocept.com wrote:
 So I'd like to propose to do the split the other way around: Not
 extract the core into something else and leave only a hollowed-out
 shell of integration and miscellany stuff behind, but rather tighten
 zope.component to its core and move the optional integration bits out
 of it, into separate packages.

 I would agree if we were starting over.  But the damage is done
 and stripping zope.component to its core would be backwards
 incompatible now.

Why? zope.component already uses extras_require to signify the various
integration parts: [persistentregistry,security,zcml].

As far as I understand the thrust of the zope.registry effort, it is to
untangle those to make porting easier (which requires those bits not to
be in the same package, I guess, because of import problems or
whatnot?).

I think the same effect could also be achieved by splitting these
integration bits into separate packages, and leaving the
extras_require's in zope.component to depend on said new packages,
couldn't it?

But that's only technicalities in search of meaningfully preserving the
name zope.component for the core package (because that's the name it
always had), and...

 This is, OTOH, an opportunity to maybe come up with a more appealing
 name.  While I like the term component, my sense is that it probably
 feels too heavy to a lot of Python programmers.  Registry is at least
 as bad and doesn't reflect the real use case.

... I agree that an alternative is to give the core a new name.

However, what's important to me is that we try to make packages
cohesive, and that we try to make integration between packages
understandable.

The current zope.component, because it came out of the Zope3 monolith,
contains integration bits to various other Zope packages:
- zope.event
- zope.security
- zope.configuration
- ZODB

In that light, it makes a lot of sense to me to have two (or more?)
packages, core and integration, but I'd *very* much like them to be
named in a way that one can tell this fact from their names.

What remains is the issue that zope.component *also* contains code for
the thread-local site concept -- which doesn't feel like an integration
with another package, but might not be considered core functionality,
either (I'm not sure yet but I lean towards considering it core).

Wolfgang

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


Re: [Zope-dev] RFC: Proposal for merging jbohman-zope.registry branch of zope.component

2011-08-25 Thread Wolfgang Schnerring
Hello,

* Tres Seaver tsea...@palladion.com [2011-08-16 22:50]:
 The focus of the 2011 Pyramid GSoC project has been to port crucial
 Pyramid dependencies to Python3. At the end of this year's US PyCon,
 Lennart Regebro labelled[1] zope.component as high-hanging fruit,
 due to the following factors::
 
 - magic
 - Mostly tested via doctests
 - Hairy dependencies (e.g., zope.proxy, zope.security)
 - Many more optional / testing dependencies (ZODB3, zope.schema,
   zope.configuration, etc.)
 
 Based on IRC discussion at project kickoff[2], Joel Bohman, one of the
 two Pyramid GSoC students, has tackled this issue by factoring
 zope.component into two pieces:
 - Joel has moved the core registry bits into a new 'zope.registry'
   package, now hosted in the Zope SVN repository:
 - Joel made zope.component depend on zope.registry in a branch:

I applaud both the direction of porting to Python3 and the drive
towards cleaning up / streamlining the ZTK packages. That's great!

However, I feel that this extraction of the registry bits is a little
too mechanical, and I'd like us to think a little bit about
alternative approaches before we commit this.

I envision the ZTK packages (like zope.component) to become more
standalone, less coupled to the whole Zope world, but cohesive
pieces of functionality that can stand on its own.

In that light, I'd like to ask: what should be in zope.component, and
what shouldn't? My first stab at an answer goes something like this:

zope.component (aka the Zope Component Architecture) consists of
- the Registry concept
- filling out the Adapter concept of zope.interface
- the Site concept (setSiteManager, aka hooks.py)
- integration with zope.event (? a bit unsure here)
Something like that would make a coherent, usable package, I think.

At the moment, though, zope.component also contains (triggered via
different extra_requires):
- integration with zope.configuration (the adapter/ and utility/ directives)
- integration with zope.security
- integration with ZODB (persistent registries)

Those integration bits with other parts of the Zope world don't need
to be in there, I guess -- and as I understand it, precisely those are
the hairy dependencies that impede porting to py3.

So I'd like to propose to do the split the other way around: Not
extract the core into something else and leave only a hollowed-out
shell of integration and miscellany stuff behind, but rather tighten
zope.component to its core and move the optional integration bits out
of it, into separate packages.

What do people think?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com · software development
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Python, Pyramid, Plone, Zope - consulting, development, hosting
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] fanstatic and preprocessors

2011-04-14 Thread Wolfgang Schnerring
Hi,

is this the right place to ask stuff about fanstatic?

Unfortunately I haven't had the opportunity to have a proper look at
fanstatic (yet!), but I've just been reading about SASS and
CoffeeScript, which are preprocessors/compilers for CSS and
JavaScript. So I wondered whether it is within fanstatic's scope that
one could feasibly write a plugin to support something like this.
Something like, I drop a foo.coffee file somewhere and it would be run
through the CoffeeScript compiler, probably cached, and served to
clients as foo.js.

(This thought has been triggered by what Rails is doing right now[1]
which is powered by their equivalent resource manager[2].)

Wolfgang


[1] 
http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
[2] https://github.com/sstephenson/sprockets
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component test isolation

2011-04-04 Thread Wolfgang Schnerring
Hi,

it seems to me this has stalled somewhat, so I wanted to ask what
people's conclusions are.

* Wolfgang Schnerring w...@gocept.com [2011-03-26 13:41]:
 * Martin Aspeli optilude+li...@gmail.com [2011-03-26 11:22]:
 On 26 March 2011 08:11, Wolfgang Schnerring w...@gocept.com wrote:
 I don't think a fixture of package foo's configuration except
 component X and Y is all that useful.

Whether the the unregister use case is useful remains debatable, but I
personally don't care all *that* much for it, so if the consensus is
that it's overkill I'll go along I guess.

I do care quite a bit for proper getSiteManager() support...

 We do definitely need to allow the global site manager to be stacked
 (which you can achieve with __bases__ as in plone.testing,
 unregistration notwithstanding). But once you do that, the rest is
 pretty easy. The local site manager will always have the global as one
 of its (nested) __bases__.

 I'm sorry, but no, it isn't that easy. When the only local site
 consumer is zope.site, well, maybe. But please think of this in terms
 of zope.component *only*.

 Its API is getSiteManager.sethook(callable), and AFAICT the contract
 is that the return value of callable must provide IComponents
 (briefly: get* and register*). Nowhere does it say that you have to
 delegate back to the global registry, and neither it should. To bring
 up Pyramid once again, they explicitly don't, because they want to
 allow several applications (thus, several registries) coexisting in
 the same process.

 And since we can't assume this delegation, I think there is no other
 way to properly do the stacking than to bend getSiteManager.

... as described here, though. And I wonder if I'm missing something,
because to do that properly looks like quite the can of worms to me.

So, how can we proceed here? Should I (and Thomas) try to get a
proof-of-concept implementation of this based on plone.testing? Or should
we think about what it takes to merge most of plone.testing's ZCA
support into zope.component itself first?

Wolfgang

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


Re: [Zope-dev] New test summarizer format

2011-03-30 Thread Wolfgang Schnerring
Hi,

* Adam GROSZER agroszer...@gmail.com [2011-03-29 11:15]:
 On Thu, 24 Mar 2011 10:51:44 +0100 you wrote:
  So. Theuni says, the code[1] (based on the current aggregator script)
  is probably pretty much ready for deployment. This is a script to be
  run by cron that scrapes the HTML list archives of the zope-test list.
  I haven't looked at it yet, so I don't know how ready probably pretty
  much actually means.
  [1] http://zope3.pov.lt/trac/browser/Sandbox/ctheune/testsummarizer
 
  If I understood this correctly, the current aggregator runs courtesy
  of Stephan Holek. I guess it would be a good idea to get this
  somewhere closer to the Zope Foundation, so I'd rather we work
  something out with Jens Vagelpohl how/where to run this than throw it
  up on one of our boxes here at gocept.
 
  Adam, do you want to tackle this? Otherwise, I can do it, but I don't
  know when I get enough round toits to make it happen.
 
 I'm rather busy nowadays.
 But it seems like it's about bugging Stephan Holek to stop the current 
 one and bugging Jens to start the new one, or? Unless the script is broken.

 Could you run that script -- worst case we'll have 2 mails for a day -- 
 for testing? Seems like it has the settings for gocept and I don't 
 really have an SMTP server here handy.

I'd really rather not duct-tape this... Alright, then I'll try and get
it into running shape and bug people to run it. And unfortunately the
code looks like it needs some work before it can be deployed properly.
 
Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] [buildout] private releases

2011-03-30 Thread Wolfgang Schnerring
* Christian Theune c...@gocept.com [2011-03-30 13:18]:
 On 03/30/2011 07:12 AM, Wolfgang Schnerring wrote:
  * Martijn Pietersm...@zopatista.com  [2011-03-29 20:59]:
  On Tue, Mar 29, 2011 at 14:16, Adam GROSZERagroszer...@gmail.com  wrote:
  ...and just dump the .tgz sdists in that folder.
  Well the problem is that it's not always so simple.
  For me a release process is preferably a single command or a single
  click on a button.
 
  Both zest.releaser and jarn.mkrelease offer you simple single-command
  release options. I use jarn.mkrelease to make releases to private,
  password protected folders on our dist.jarn.com 'egg server' (apache
  directory indexes).
 
  (Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for
  zest.releaser that allows uploading the created egg via scp. We use this
  to put our non-public eggs into a folder that's served (and htpasswd
  protected) by an Apache or somesuch, no complicated egg server
  business required.
 
 So those solutions then require you to put the password for accessing it 
 somewhere during deployment ... where is that for you?

We put the password into the buildout.cfg.

Wolfgang
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] [buildout] private releases

2011-03-29 Thread Wolfgang Schnerring
* Martijn Pieters m...@zopatista.com [2011-03-29 20:59]:
 On Tue, Mar 29, 2011 at 14:16, Adam GROSZER agroszer...@gmail.com wrote:
 ...and just dump the .tgz sdists in that folder.
 Well the problem is that it's not always so simple.
 For me a release process is preferably a single command or a single
 click on a button.

 Both zest.releaser and jarn.mkrelease offer you simple single-command
 release options. I use jarn.mkrelease to make releases to private,
 password protected folders on our dist.jarn.com 'egg server' (apache
 directory indexes).

(Shameless plug: ;-) gocept.zestreleaser.customupload is a plugin for
zest.releaser that allows uploading the created egg via scp. We use this
to put our non-public eggs into a folder that's served (and htpasswd
protected) by an Apache or somesuch, no complicated egg server
business required.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Test fixture concepts

2011-03-28 Thread Wolfgang Schnerring
Hello,

* Martin Aspeli optilude+li...@gmail.com [2011-03-27 16:13]:
 On 27 March 2011 15:54, Uli Fouquet u...@gnufix.de wrote:
  The (limited) experiences with py.test, however, were awesome. Some
  points that are quite cool IMHO: [...]

I agree wholeheartedly with what Martin has said about py.test vs.
zope.testrunner.

  - Lots of setup code (unrelated to fixtures) can simply be skipped. No
  need to do the ``testsuite = complex-testcase-collecting`` over and
  over again. Maybe the main point of py.test.
 You don't need that for zope.testrunner either, of course, at least
 not when using unittest base classes.

This is a point that bears repeating, though: test_suite() is *not
needed* since zope.testing-3.8.0 (2009-07-24) for descendants of
unittest.TestCase.

 FWIW, I think we should stop using .txt doctests for unit tests.
 Doctests should be used to test *documentation* (the examples are
 valid). For actual unit tests, writing tests in a unittest class is
 almost always better in the long run.

+lots and lots and lots,
especially since you've formulated it in quite a balanced way.

  For now I think that there is absolutely no need to think about a
  general move to py.test for the ztk.
 
 I think there's benefit in unifying the concepts and support for
 concepts like layers so that people can use the test runner they
 prefer.

How can we make progress here? I'm not sure whether this calls for
some green field sketching, how should test fixture setup work? or
some hands-on experimentation, let's see how we get some existing
test layers to run under py.test, or both, or something else
entirely.

Wolfgang
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Test fixture concepts

2011-03-28 Thread Wolfgang Schnerring
Hello,

* Jim Fulton j...@zope.com [2011-03-28 10:04]:
 More generally, I'd love to see us adopt another test runner so that
 we can stop maintianing zope.testrunner.  When it was written at
 the turn of the century, there weren't good alternatives.  Personally,
 I think maintaining it is boring.

I agree, it would be nice to get out of the test runner business, just
as we're getting out of the networking business more and more courtesy
of WSGI. But I'm wary of throwing out the baby with the bathwater,
zope.testrunner has quite a few features under the hood that are
really useful, which I'm not sure other test runners have, and I
definitely wouldn't want to lose. Layers are the most prominent, of
course, but then there's post-mortem debugging (-D), coverage
integration, ... the list goes on for a few more items, I'm certain.

I guess, apart from the layer issue (see other messages in this
thread), some research and write-up would be a good idea to get a
feeling what the other test runners are like and how they measure up
against zope.testrunner. A quick google search turns up nothing
appropriate, so I might do a comparison of zope.testrunner, py.test
and nose, but that's going to take a while.

Wolfgang
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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 world

2011-03-28 Thread Wolfgang Schnerring
Hello,

* Sebastien Douche sdou...@gmail.com [2011-03-28 13:26]:
 On Sat, Mar 26, 2011 at 15:18, Wolfgang Schnerring w...@gocept.com wrote:
 An honest counter question: Why not use zope.testrunner? What
 advantages does py.test offer?

 On the technical side, I don't know. But from my point of view, the
 most important thing is the social side. I'm a bit tired to be
 compartmentalized : you must use generics tools (Nose, WebOb,
 Paster...) or Zope tools (Zope3, KGS, zope.testbrowser, zope.testing,
 zc.buildout, z3c.testsetup...).

I'd like to clarify that I've asked the question not to exclude py.test,
but on the opposite, to *include* it into consideration. So I think we're
actually in agreement with each other. :-)

Wolfgang

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


Re: [Zope-dev] zope.component test isolation

2011-03-26 Thread Wolfgang Schnerring
Hello,

* Martin Aspeli optilude+li...@gmail.com [2011-03-25 13:58]:
 plone.testing (which is Plone non-specific and will shortly be BSD
 licensed) allows for stacking of ZCA registries.
 [...]
 Again, plone.testing is the result of hours and hours of finding weird
 problems, so I'd recommend you don't discard the knowledge there. I
 think a best case scenario would be for plone.testing.zca to just be a
 delegate for something more robust in zope.component.testing.

I wasn't aware plone.testing had something for the ZCA, before I read
that in this thread yesterday. I'm glad to hear that, and I certainly
don't want to discard anything. But from reading the code and what you
wrote, I get the impression that plone.testing does not yet solve the
issue completely, precisely because of the two points I brought up and
that continue below:

 On 25 March 2011 13:17, Jim Fulton j...@zope.com wrote:
  On Fri, Mar 25, 2011 at 4:24 AM, Wolfgang Schnerring w...@gocept.com 
  wrote:
   we realized that just squeezing in a new registry and bending its
   bases to the previously active one is not enough for full isolation,
   since this does not cover *deleting* registrations
 
  Is deleting registrations important?  This seems like an odd use case.
  If it's needed, I would suggest starting with a baseline (e.g. stack)
  that doesn't include the component you want to test deleting, then
  adding in setup.

I've wanted to specifically nuke registrations sometimes, the pattern
being, load the package's configure.zcml in the layer, and then delete
something (to demonstrate some error handling behaviour).

I agree that this use case is rare, but I'm not sure it is rare enough
that we should ignore it. I need to think about this some more,
though.

   2. zope.component has two entry points, the global site registry and
   the current registry (getGlobalSiteManager and getSiteManager).
   The current registry can be anything, or more precisely, you can call
   getSiteManager.sethook(callable) and provide a callable that returns
   the current registry.
  
   I think to provide test support for zope.component (i. e. generally,
   at the library level), we need to support both entry points.
 
  Why? Why would someone care about anything other than the current
  effective configuration.

Because that's the API that zope.component offers, it conceptually
deals with *two* registries: the one you get from getSiteManager and
the one you get from getGlobalSiteManager.

I agree that it is unlikely that client code will *read* registrations
using getGlobalSiteManager -- since most everyone uses
zope.component.getUtility etc. (which in turn uses getSiteManager).
But *writing* is a different matter. Just one example:
zope.component.provideUtility etc. uses getGlobalSiteManager, while
the ZCML directives use getSiteManager.

At least as long as zope.component.provide* uses getGlobalSiteManager
instead of getSiteManager, I maintain that test infrastructure needs to
1. wrap the global registry
2. wrap whatever getSiteManager currently returns
(Otherwise we might be able get away with not doing (1), but I think
we'll always need to do (2).)

plone.testing has it the other way around, doing (1) but not (2), as
Martin says himself...

   The global one is not hard, but the getSiteManager one gets
   nasty really fast, because of course we have to rely on bending
   getSiteManager to return the current test registry
 
 I don't think you need to do that. plone.testing doesn't, for sure, it
 just changes the variable that getSiteManager() looks at.

... and I'm quite sure that's wrong, becasue it doesn't deal with the
issue of getSiteManager at the level of zope.component, but at the
level of some specific implementations (zope.site and
five.localsitemanager, to be precise). When I'm using, say, Pyramid
(which also uses getSiteManager.sethook), this won't help me at all.

And to do this on the level of zope.component, I'm quite sure we are
going to need to override getSiteManager.

   but anyone could at any time call getSiteManager.sethook to
   change it!
  
  Seriously?  Nobody calls that but deep infrastructure code.

 Agree with Jim. Are you going to stop people monkey patching
 getSiteManager() too? ;-)

My point is: Ensuring that test setup always and everywhere happens
precisely so that the code that calls sethook (for example the setup
of zope.site) is called *before* the envisioned test infrastructure
code comes along to bend getSiteManager to do its will seems very
fragile to me, if it's doable at all.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https

Re: [Zope-dev] zope.component test isolation

2011-03-26 Thread Wolfgang Schnerring
Hello,

* Martin Aspeli optilude+li...@gmail.com [2011-03-26 11:22]:
 On 26 March 2011 08:11, Wolfgang Schnerring w...@gocept.com wrote:
  * Martin Aspeli optilude+li...@gmail.com [2011-03-25 13:58]:
 Please also take my word for it when I say that copying the whole
 registry is non-trivial and would rely on brittle ZCA internals. I
 tried. :)

I tried, too, and yup, in the end you'd have to write C to do it
properly (because the AdapterLookupBase or something in zope.interface
is written in C and would need to gain __deepcopy__ support).
But it didn't seem unfeasible, and, when it was all said and done in
Python, not very ugly either.

I appreciate that you've already fought (and won!) against the
whole persistence story (which hadn't even been on my radar so far),
and I guess copying would necessitate reopening that can of worms.

  I've wanted to specifically nuke registrations sometimes, the pattern
  being, load the package's configure.zcml in the layer, and then delete
  something (to demonstrate some error handling behaviour).
 
 I think you either need to consider a package's ZCML-loaded
 configuration as an atomic part of test setup, or you need to break it
 down into individual registrations. In the first case, your test
 fixture is package foo's configuration is loaded, which is of course
 valid. In the second case, your fixture is the following components,
 some of which happen to be in package foo, are registered.
 
 I don't think a fixture of package foo's configuration except
 component X and Y is all that useful.

It seems I can't convey why I think that precisely this is valuable
even without taking into account the desire for non-leaky
abstractions (in the ZODB-analogy it would be quite strange to have to
write on top, please don't delete stuff, it's not supported).

And of course I know how one could work around the limitation that
unregistering is not supported. That doesn't make it any less
inconvenient.

The other point about getSiteManager below is *much* more important
than unregistration support, though:

  Because that's the API that zope.component offers, it conceptually
  deals with *two* registries: the one you get from getSiteManager and
  the one you get from getGlobalSiteManager.
 
  I agree that it is unlikely that client code will *read* registrations
  using getGlobalSiteManager -- since most everyone uses
  zope.component.getUtility etc. (which in turn uses getSiteManager).
  But *writing* is a different matter. Just one example:
  zope.component.provideUtility etc. uses getGlobalSiteManager, while
  the ZCML directives use getSiteManager.
 
  At least as long as zope.component.provide* uses getGlobalSiteManager
  instead of getSiteManager, I maintain that test infrastructure needs to
  1. wrap the global registry
  2. wrap whatever getSiteManager currently returns
  (Otherwise we might be able get away with not doing (1), but I think
  we'll always need to do (2).)
 
  plone.testing has it the other way around, doing (1) but not (2), as
  Martin says himself...

 We do definitely need to allow the global site manager to be stacked
 (which you can achieve with __bases__ as in plone.testing,
 unregistration notwithstanding). But once you do that, the rest is
 pretty easy. The local site manager will always have the global as one
 of its (nested) __bases__.

I'm sorry, but no, it isn't that easy. When the only local site
consumer is zope.site, well, maybe. But please think of this in terms
of zope.component *only*.

Its API is getSiteManager.sethook(callable), and AFAICT the contract
is that the return value of callable must provide IComponents
(briefly: get* and register*). Nowhere does it say that you have to
delegate back to the global registry, and neither it should. To bring
up Pyramid once again, they explicitly don't, because they want to
allow several applications (thus, several registries) coexisting in
the same process.

And since we can't assume this delegation, I think there is no other
way to properly do the stacking than to bend getSiteManager.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Test fixture concepts (was: Zope test layers, pytest, and test isolation)

2011-03-26 Thread Wolfgang Schnerring
Hello,

part two. :)

* Uli Fouquet u...@gnufix.de [2011-03-24 01:05]:
 A big advantage of test layers over `pytest` testing scopes might be
 that you can spread your tests associated to a certain layer over many
 files/modules/packages as you like and the setup/teardown will
 nevertheless only be performed once for each layer
 
 Compared to Zope test layers I came to the conclusion that there is not
 much like this concept already in `pytest` and the behaviour of test
 layers can not easily be faked.

I fully agree, the test layer concept of zope.testrunner provides some
very nice properties, most notably:

1) Shared fixture setup. It is shared across many TestCases and
created only once per test run. (And it is independent of how the
tests are organized into modules or whatever.)

2) Stacking of fixture setups. My canonical example: First, we
initialize the application, load ZCML, prepare databases, etc. and
talk to it with zope.testbrowser. That's the first layer. Then we add
a HTTP port with gocept.selenium on another layer and do the rest with
a real browser -- but the whole, possibly expensive, application setup
*does not have to be done again*.

3) Orthogonal composition, i.e. you can have small, well defined
fixture units that you can then combine in a separate step to form the
actual setup for your tests. This enables for example that library
packages like zope.component could provide test infrastructure for
themselves, and application packages could pull all the test
infrastructure together that they need -- not like zope.app.testing
for example, which is a giant monolith that sets up everything at
once.

I think that these properties are very valuable, and I haven't seen them
anywhere else so far. I haven't looked at py.test closely, yet, but
from what I've seen, and what you wrote, it doesn't seem to offer
these things right now.

 Would it make sense to bring the Zope layer concept into `pytest`?
 
 Are there already possibilities to mimic testlayer-like behaviour in
 `pytest` which we simply overlooked?

An honest counter question: Why not use zope.testrunner? What
advantages does py.test offer?

But your email brings into focus a question that I've been thinking
about lately: What's the future direction for test fixture setup?

Because, while test layers are nice because they have the above
properties, I'm not too happy with the current implementation, namely
the use (or is it abuse? ;-) of __bases__ and __name__, which leads
very naturally to not-so-helpful implementation patterns. As a
concrete example, some of the test layers of ZTK packages, most
notably the successors of zope.app.testing.functional in
zope.component, zope.app.appsetup, zope.app.wsgi, are implemented
right now in a way that does not have properties 2+3.

The most straightforward way to improve that situation would be to use
plone.testing, since that provides a layer implementation that is both
sane and easy to use, and has all the nice properties. (Maybe even
fold some of it into zope.testrunner itself.)

But then I realized, that's a major undertaking, so we better think
about what the actual goals are before changing lots of stuff. And
then I heard people expressing interest in other test runners.
(py.test and nose seem to be the biggest players, stdlib's
unittest/unittest2 seems to be woefully behind in terms of test
selection and other features like coverage or debugging. I for one
happen to like zope.testrunner, but if there's a good alternative, why
not combine our efforts?)
I also found that it is rather hard to explain how to use test layers
in a way so you actually get the above properties, so I started
wondering whether there was a cleaner way to get them.

So I guess I have three questions:

1. (The starting point:) How can we improve the test infrastructure
situation of the ZTK packages?

2. (The main thing:) Are test layers, both the concept and the
implementation as epitomized by plone.testing, the way to go or is
there a cleaner alternative?

3. (But only tangentially, I don't want to sidetrack the discussion at
hand nor start a flamewar:) Is there a compelling alternative to
zope.testrunner that would make it worthwile to think about either
generalizing the fixture support or even migrating away from
zope.testrunner?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.component test isolation (was: Zope test layers, pytest, and test isolation)

2011-03-25 Thread Wolfgang Schnerring
Hello Uli,

I've spent quite some time thinking (and partly coding) about the same
issues you mention (but didn't feel ready to talk about it here, yet),
so I'm glad that maybe we can start thinking about them together

I think your email addresses two quite different topics, so I'll split
my reply. First up: test support for zope.component. Second part:
about the concept of test layers.

* Uli Fouquet u...@gnufix.de [2011-03-24 01:05]:
 Right now we have a problem with pytest integration when it comes to
 ZCA setups [...] all tests share the same global ZCA registrations
 and changes to the registrations in one test will affect other tests
 run thereafter. We have a lack of test isolation.

Exactly. This issue has bitten me too in various places, and as far as
I know there are no solutions for it, yet.

What I envision to solve this issue is that test support for
zope.component should work the same way as with the ZODB. There, we
have a *stack* of Databases (DemoStorages, to be precise) that wrap
each other, where each one delegates reads downwards, but keeps writes
for itself. So you might have one database for the layer that provides
the baseline, and each test (in its setUp) gets its own database where
it can do whatever it wants, because it is thrown away in its
tearDown.

In principle, quite a few of the mechanics to do the same thing with
zope.component registries are already there (since a registry keeps a
list of base registries it will delegate to when something can not be
found in itself). And as Hanno and Godefroid mentioned, plone.testing
does something in this direction already. (And, it bears repeating,
in its core has no dependencies on Plone or Zope2.)

But as far as I see, there are issues that plone.testing does not
address:

1. I've been going over this stuff with my colleague Thomas Lotze, and
we realized that just squeezing in a new registry and bending its
bases to the previously active one is not enough for full isolation,
since this does not cover *deleting* registrations (one, you can only
delete the registration from the precise registry it was created in,
and two, in the just-bend-the-bases approach, once you delete a
registration, it's gone forever).

I think to provide full isolation, we need to make *copies*. And since
zope.component in general supports a chain of registries, we probably
need to make copies of each of them.

2. zope.component has two entry points, the global site registry and
the current registry (getGlobalSiteManager and getSiteManager).
The current registry can be anything, or more precisely, you can call
getSiteManager.sethook(callable) and provide a callable that returns
the current registry.

I think to provide test support for zope.component (i. e. generally,
at the library level), we need to support both entry points. The
global one is not hard, but the getSiteManager one gets nasty really
fast, because of course we have to rely on bending getSiteManager to
return the current test registry -- but anyone could at any time
call getSiteManager.sethook to change it! Which means we need to
intercept that and a) prevent our hook from being replaced and b)
inject the new registry into the test stack somehow.

As far as I understand, plone.testing sidesteps these issues by only
dealing with the global registry, and specially munging the two known
cases in the Zope world where getSiteManager is changed (zope.site and
five.something).

**

I'd like to know what people think about this plan.
Thomas and I have been over this quite a bit and think it's sound, not
overly complicated, and (after we did some experiments) definitely
doable. Please do point out stuff we missed. :-)

I'd very much like to put this functionality into zope.component
itself, which of course raises backwards compatibility issues galore,
but any code for this definitely isn't wasted since we can always
package it separately if we don't find a way to integrate it.

Thomas and I taken up implementing this, but we can't devote a lot of
time to it (about one session per week), so realistically I'm afraid I
guess it will take a few months until we have something of substance.
So if there are people who want to pitch in, that'd be great. I
definitely could write up a more detailed plan and maybe even
formulate smaller chunks so we could go at this with more people.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New test summarizer format (was: We need to get the board green)

2011-03-24 Thread Wolfgang Schnerring
Hello,

* Adam GROSZER agros...@gmail.com [2011-03-23 08:45]:
 On Wed, 23 Mar 2011 07:43:26 +0100 you wrote:
  On a tangentially-related note, what happened to the proposed new
  summarizer formatting? Half a year ago (or whenever), I got the
  impression it was going to be ready in a few days, but it seems it
  never happened. What is needed to get this switched?
 
 You mind walking over to Theuni and asking him? ;-)

Oh. Right. Sure.

*walks over and back*

So. Theuni says, the code[1] (based on the current aggregator script)
is probably pretty much ready for deployment. This is a script to be
run by cron that scrapes the HTML list archives of the zope-test list.
I haven't looked at it yet, so I don't know how ready probably pretty
much actually means.

If I understood this correctly, the current aggregator runs courtesy
of Stephan Holek. I guess it would be a good idea to get this
somewhere closer to the Zope Foundation, so I'd rather we work
something out with Jens Vagelpohl how/where to run this than throw it
up on one of our boxes here at gocept.

Adam, do you want to tackle this? Otherwise, I can do it, but I don't
know when I get enough round toits to make it happen.

Wolfgang

[1] http://zope3.pov.lt/trac/browser/Sandbox/ctheune/testsummarizer

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] We need to get the board green

2011-03-23 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2011-03-21 16:56]:
 Too many never-resolve failures in our buildbots makes their output just
 noise:  the amount of effort required to diagnose the cause of a failure
 seems to have no payoff if we don't get them each cleared up.

On a tangentially-related note, what happened to the proposed new
summarizer formatting? Half a year ago (or whenever), I got the
impression it was going to be ready in a few days, but it seems it
never happened. What is needed to get this switched?

(I'm not saying dressing the continuous failures up nicer is a solution
to the problem Tres is presenting, but I do think the noisy format
contributes to the confusion about the buildbots)

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser and WebTest (round 2)

2011-03-02 Thread Wolfgang Schnerring
Hello Brian,

it's taken a while, but I finally had a chance to review your branch(es).

* Brian Sutherland br...@vanguardistas.net [2011-02-12 18:57]:
  On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
  I'd prefer if we treated this as two separate steps, then:
  a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with 
  WebTest

 I pulled this out of my original branch and put it here:
 svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal

Thanks, that helped me understand what's going on much better.

I do have a few questions about this part:

- Does the (webtest-based) wsgi.Browser behave similarly to the
  Publisher-Browser?

When we ported the wsgi_intercept variant from zope.app.wsgi, we found
that there were some idiosyncracies woven in that people may rely on.
This kind of stuff of course isn't documented, and we didn't do much
research, but rather took care to port what we found in zope.app.wsgi,
namely filtering some HTTP headers from the response (meh, doesn't feel
important), and handling Basic Auth headers (that feels important to
preserve).

- What should happen in zope.app.wsgi?

We moved the wsgi-based Testbrowser from there and left BBB imports to
zope.testbrowser.wsgi, taking care to be API compatible. I guess that
won't be possible with the WebTest-based Testbrowser (or would it?),
so we probably have to break that. (Hmm, would that imply a major version
bump there, too?)

Since the Grok people are the ones who probably use the zope.app.wsgi
Testbrowser the most, they should probably take the WebTest-Testbrowser
for a test drive and see whether it works for them, otherwise we're
going to make them quite unhappy if we just break zope.app.wsgi.
(Could you ask on grok-dev about that? I guess it's too buried here to
be noticed.)

- What's connection.py?

I don't really understand where that came from or what its purpose is,
especially since wsgi.py seems to be the only one that uses it?

Ah. I take that last bit back, the extracted Publisher-Browser in
zope.app.testing uses it, so I guess this is a split-off artifact of the
refactoring/extraction.

But I still don't really understand what it is all about. %-)

- The layer looks good. (OK, so that's not a question ;)

I'm glad you found a way that the browser can get the application out
of the air. I've tried the explicit passing way on a project of mine,
and it's a huge hassle (I've ended up stuffing a preconfigured browser
instance into the doctest globs, ugh.)

I think it would be good if the layer stored the application of
self.app, we did that in the wsgi_intercept variant and were glad of it
a few times already.

  b) extract the testbrowser part that talks to the Publisher

 This is here and by necessity includes the changes for step (a):
 svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3
 
 svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser

The extraction of the Publisher-Browser makes a lot of sense, and looks
clean to me, as does the rewrite of the tests to use a plain WSGI app
instead of a Zope-based app.

 I would much prefer to merge both steps together.

Yes, I guess that makes sense because only step (b) includes proper
tests for everything.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser and WebTest (round 2)

2011-02-12 Thread Wolfgang Schnerring
Hi,

sorry I'm replying this late. I've been busy, then sick, then busy
again, so I'm afraid this has got pushed low on my stack of stuff...

* Brian Sutherland br...@vanguardistas.net [2011-02-02 11:15]:
 On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote:
 * Brian Sutherland br...@vanguardistas.net [2011-01-31 09:54]:
  On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
 Ok, I think that that API is preservable. However I would like to make
 the layer optional by adding an wsgi_app keyword argument to Browser. So
 you can do:

  browser = Browser(wsgi_app=app)

 where app is a WSGI application.

 Some people in the non-zope world are not too fond of layers, or use
 incompatible testrunners. We shouldn't force layers on them.

Yes, we definitely don't want to require layers here. This has not been
an issue so far, since both the publisher and the wsgi_intercept method
inject the application to the browser by looking it up via the special
hostname 'localhost', but now we need to pass in the WSGI callable
explicitly.

I do think that mostly one will want to prepare the WSGI callable only
once, and thus a layer is a good fit, but that should be optional.

 I'd prefer if we treated this as two separate steps, then:
 a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with 
 WebTest
 b) extract the testbrowser part that talks to the Publisher

 Initially I did them together because it was the only way to get very
 good test coverage of the WebTest integration. If we do it this way,
 between steps a and b we'll have poor coverate. But that's not so bad as
 the code has already been well tested on my current branch.
  
 As to (a), I'll still need to look at your code, but as I said I'm
 all in favour of using WebTest instead of wsgi_intercept.

 I'll try make a branch for this in the next week or so for you to review.

Thanks very much, I'll look throught it as soon as I find some time,
probably not next week (I'm travelling), but hopefully the week after
that, at the latest.

 As to (b), I saw you moved the code to zope.app.testing. I have a
 few ideas in that area which I'll contact you off-list about.
 Sure!

As we've discussed off-list, we now both feel that moving the
publisher-testbrowser to zope.app.testing is a good idea, since the only
applications that will want to use that testbrowser are those that use
zope.app.testing -- the more modern approach of testing publisher-based
applications is to use the code from zope.app.wsgi to create a WSGI
application and then use the WSGI-enabled testbrowser to talk to that.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser and WebTest (round 2)

2011-02-01 Thread Wolfgang Schnerring
* Wichert Akkerman wich...@wiggy.net [2011-01-31 09:46]:
 On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
 So I'm curious: What are the differences bewteen WebTest and
 wsgi_intercept? Is one preferable to the other?

 If I remember correctly WebTest wraps the WSGI app object directly and 
 does not require monkeypatching urllib. To send requests to the app 
 under testing you call WebTest post/get methods, which directly call the 
 WSGI app.

Thanks for clarifying, that does indeed make sense. I guess I should
have researched wsgi_intercept and WebTest in more detail. :/

* Brian Sutherland br...@vanguardistas.net [2011-01-31 09:54]:
 On Mon, Jan 31, 2011 at 07:02:35AM +0100, Wolfgang Schnerring wrote:
 I'd very much like there to be *one* way of doing WSGI with the
 testbrowser, and at first blush I don't care whether that's WebTest or
 wsgi_intercept or whathaveyou, as long as it fulfills its purpose. 

 We have already committed to wsgi_intercept integration for the long
 term. It was released in zope.testbrowser 3.11 a few days ago, right? If
 we are to have only one way to do this, then wsgi_intercept must be it.

I definitely don't see this as set in stone, *at all*. Yes, we've had a
release that uses wsgi_intercept for talking to WSGI apps. (And yes, we
didn't ask anyone for their opinion on it, and I'm sorry about that.
However, I guess the development process in the Zope community is an
entirely different issue, sigh.)

But I feel the important point about this regarding compatibility is not
the underlying technology, but the API, i. e. that
- zope.testbrowser.wsgi.Browser is a Testbrowser
- zope.testbrowser.wsgi.Layer with a method make_wsgi_app is there to
facilitate the test setup.

I think as long as we preserve this API (which seems sound to me, but of
course I'm biased ;-), we're free to change stuff under the hood.

 But I'm ambivalent about only having one way to do things. I think
 having both integrations in zope.testbrowser is not such a bad thing.
 Having the test suite run over 2 different integrations is definitely
 good.

Maybe I'm missing something, but when I think about the task at hand
from the client's perspective, then the only sentence that matters to me
is, give me a zope.testbrowser that talks to this WSGI callable.

Which means a) I couldn't care less how that's done internally as long
as it doesn't cause me any hassle and, more importantly b) I do *not*
want to have to think about it and/or make a choice about the underlying
mechanism. I want the library to have done that research (as we are
doing right now). And to me this task seems straightforward enough to
not warrant pluggability -- on the contrary, I feel it's so narrow in
scope it outright *forbids* it (but again, I may be missing something).

 I'll gladly review your branch, but I'd like to know the motivation
 behind it.

 Only ~30% of the branch is the implementation of the WebTest connection.

 The other ~70% of the branch is a refactoring of the test suite. That's
 where the reduction in test dependencies comes from. The test fixture on
 the branch is a reasonably minimal WSGI application run via the WebTest
 connection.

I'd prefer if we treated this as two separate steps, then:
a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with WebTest
b) extract the testbrowser part that talks to the Publisher

As to (a), I'll still need to look at your code, but as I said I'm
all in favour of using WebTest instead of wsgi_intercept.

As to (b), I saw you moved the code to zope.app.testing. I have a
few ideas in that area which I'll contact you off-list about.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser and WebTest (round 2)

2011-01-30 Thread Wolfgang Schnerring
* Brian Sutherland br...@vanguardistas.net [2011-01-30 16:04]:
 I've finally finished refactoring my WebTest/testbrowser branches,
 basically doing this:

 - Integrate with WebTest. zope.testbrowser.webtest.Browser is a new
   Browser implementation that uses webtest.TestApp to drive a WSGI 
   application. This allows simple and direct testing of WSGI applications.

 - Re-write the test application as a pure WSGI application using WebOb.
   Run the existing tests using the WebTest based Browser

 - Move zope.app.testing based Browser into zope.app.testing (leaving
   backwards compatibility imports in-place).

 This is a very big change, so I would appreciate anyone who would take a
 look at these branches before I merge:

Michael Howitz and I recently polished the integration of
zope.testbrowser and wsgi_intercept to accomplish pretty much the same
things you mentioned. (I'm aware that you two exchanged some emails
about it, but don't know any details).

So I'm curious: What are the differences bewteen WebTest and
wsgi_intercept? Is one preferable to the other?

I'd very much like there to be *one* way of doing WSGI with the
testbrowser, and at first blush I don't care whether that's WebTest or
wsgi_intercept or whathaveyou, as long as it fulfills its purpose. 
I'll gladly review your branch, but I'd like to know the motivation
behind it.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.form buildout broken

2010-11-22 Thread Wolfgang Schnerring
* Roger d...@projekt01.ch [2010-11-22 14:30]:
 Probably an option like --skip-part omelette whould be a nice feature for 
 buildout.

IIRC, when the parts are originally specified on separate lines

base.cfg:
[buildout]
parts = like
this
omelette
#not: parts = like this

you can do this:

buildout.cfg
[buildout]
extends = base.cfg
parts -= omelette

Don't know whether/how you can do that on the command line, though.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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.testbrowser and python2.7

2010-10-15 Thread Wolfgang Schnerring
Hello,

* Jan-Jaap Driessen jdries...@thehealthagency.com [2010-10-14 19:19]:
 The httplib.HTTPConnection API changed from python2.6 to python2.7.
 These changes are reflected in the handleErrors property of
 zope.testbrowser.browser.Browser - it is no longer possible to pass a
 boolean into the request headers.

Thanks for looking into this. Forward compatibility is a good thing.

 A fix is available on the trunk of zope.testbrowser [1]. In this
 implementation, a boolean is provided to the consumers of the
 testbrowser API and a string is used in the request headers.
 This implementation is sub-optimal in my opinion. In the branch
 'janjaapdriessen-handle-errors' [2] you will find a cleaner
 implementation, where the switch to handle_errors is controlled by the
 presence of a zope-do-not-handle-errors header.

I agree that the boolean-string translating is a bit ugly, but to be
honest, I also don't not dislike the double negative in your alternative
solution. ;-)

 This change is backwards incompatible. Code relying on the
 'x-zope-handle-errors' header will break. I have tested this
 implementation against the ZTK trunk on python2.7 and have found no
 breakage of this kind.

I'm definitely fine with changing that header name if necessary, though.
Since that's an implementation detail of zope.testbrowser, it should be
nobody else's business, and your tests seem to confirm this -- excellent.

 Please let me know if either of these solutions is OK with you. If so,
 grant me pypi rights (my handle is 'janjaapdriessen') so I can release
 zope.testbrowser and get a step closer to making the ZTK run on
 python2.7.

I don't have a *strong* opinion which serialization of that flag is less
ugly. I'm leaning towards the trunk one (no double negatives), but
either one is basically fine by me.
I've given you pypi rights for zope.testbrowser.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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

2010-10-07 Thread Wolfgang Schnerring
* Jan-Wijbrand Kolman janwijbr...@gmail.com [2010-10-06 13:39]:
 On 10/6/10 12:49 PM, Wolfgang Schnerring wrote:
 * Jan-Jaap Driessenjdries...@thehealthagency.com  [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 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.

Thanks for the explanation!
I agree with you, it would make a lot of sense to use official APIs and
not work around them. Don't know how hard that's going to be in this
case, though. ;)

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

Ah. I didn't remember that compattest indeed does generate scripts (I
thought it was delegating everything, but that's not correct of course),
and I didn't understand from Jan-Jaaps email that system-python-support
was a goal here, too, I only got the some compatibility broke part and
was confused about that.

 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.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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

2010-10-06 Thread Wolfgang Schnerring
* Jan-Jaap Driessen jdries...@thehealthagency.com [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.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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 review #181754

2010-07-20 Thread Wolfgang Schnerring
* Wichert Akkerman wich...@wiggy.net [2010-07-20 19:28]:
 On 2010-7-20 18:15, Christian Theune wrote:
 At least, WRT this bug, I don't think it's a good idea to ask explicitly
 for bad requests to go to the application as the test layer should model
 real server behaviour as closely as possible. And again it wouldn't make
 sense anyway as you can't pass an unparsable request to the application.

 I'm not sure I agree. Like everything else servers have bugs, so it 
 can't hurt to test how your application would behave given certain 
 server bugs.

I don't think it is usually a productive assumption that lower layers
fail to uphold their end of the contract. Maybe an
extrapolation/hyperbole illustrates my opinion: Cosmic rays might also
flip bits in your computer's RAM or disk, but I don't think it's
worthwile to test how your application reacts when the python
interpreter (or whoever, really) presents it with mangled data
structures or objects or whatnot.

To put it differently, yes, servers have bugs, but the place to fix them
is in the server. If we can't rely on our layers/abstractions to hold,
I feel we lose most if not all benefits of having them in the first place.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Bug tracker for zc.table

2010-06-04 Thread Wolfgang Schnerring
Hello,

I've stubmled upon an issue in zc.table, it can't deal with spaces in
column names when sorting (since it uses space as the field separator
to pass the sort_on information). I don't have time to look into this
right now, but I'd like not to forget it.

Is there someplace on Launchpad where I could file a bug for future
reference?

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


Re: [Zope-dev] Summary of this weeks' meeting (2010-03-30)

2010-04-01 Thread Wolfgang Schnerring
* Christian Theune c...@gocept.com [2010-03-31 17:16]:
 we decided to keep going with the meetings, so I'd be happy to see you
 guys next week in #zope.

I'm all in favor, it seems to me the meetings really help in moving things 
along.

 For those of you who can't/don't participate in those meetings, there's 
 the open question about how useful you consider my summaries to be. 
 Please tell!

I feel the summaries are essential: without them, those not able to
participate would very soon be out of the loop, and that's a very Bad
Thing(tm) in my opinion.

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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

2010-01-26 Thread Wolfgang Schnerring
* Martijn Faassen faas...@startifact.com [2010-01-22 22:27]:
 This is to announce my withdrawal from the Zope Toolkit steering group.

I'm saddened to hear this. I feel that many if not all of the things you
were trying to set in motion in our community are desperately needed.
I'm sorry to hear that you have been worn out trying.

Thanks for all the energy you've put into this.

Wolfgang

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


Re: [Zope-dev] A summary of Interfaces vs ZCA concepts

2009-12-18 Thread Wolfgang Schnerring
* Martijn Faassen faas...@startifact.com [2009-12-17 17:48]:
 * Thomas Lotze t...@gocept.com:
  zope.interface [should be] completely unaware of any particular uses
  of interfaces

 Why is it a problem that the zope.interface package gains knowledge 
 about adaptation (which it always had, anyway) and utility lookup? 

This is the key issue, I think.
(And I'd like to ask you not to argue it has always been that way,
since what we're trying to do here precisely is to improve the status
quo.)

The question is, which concepts belong into zope.interface and which don't?
One might also phrase that as, what is the responsibility and purpose of
zope.interface (drawing upon the software engineering terms of cohesion
and coupling).

My opinion is that

 [__call__ introduces] the following notion into zope.interface:
 please look up an object that provides this interface, somehow. (with 
 zero or more context objects)

might well belong into zope.interface, but that anything of these:

 adapters, utilities, null-adapters or contextual utilities

absolutely do not.

I think there is a clear distinction between what interfaces are about
and what component architecture is about, and I think it is worthwile
to maintain and clarify that distinction.

For me, a notion of looking up something that provides an interface
belongs to what interfaces are about.
But notions of utilities which might or might not be singletons, of
adapters which might or might not take additional parameters such as a
name to look them up, or notions of a context or a registry (which
for me comes up immediately when thinking about global vs. local
utilities) that influences the lookup, for me emphatically do *not* belong
to what interfaces are about.

By putting method stubs into zope.interface which are exclusively about
concepts of zope.component we would be
a) On a conceptual level: blurring the distinction between the two
packages and concepts, which I think is a Bad Thing(tm)
b) On a more practical level: coupling zope.interface to zope.component.
Given all the recent efforts of untangling the dependency structure
between our packages, I think doing that would be a step in the exact
opposite direction.

Wolfgang

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


Re: [Zope-dev] Adapter for class with slots

2009-12-15 Thread Wolfgang Schnerring
* Wolfgang Schnerring w...@gocept.com [2009-12-07 08:53]:
 The minimal reproduction recipe to see the error is this:
 
 class Slotted(object):
 __slots__ = ('__provides__')
 
 zope.component.provideAdapter(
 lambda x: True, (Slotted,), zope.interface.Interface)
 I'll try and see whether I can come up with a way for zope.interface to
 do the Right Thing(tm) in this situation.

I forgot to mention this here: the edge case has been fixed and released
in zope.interface-3.5.3

Wolfgang

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] Bootstrapping ZCA for Python 3.

2009-12-06 Thread Wolfgang Schnerring
* Lennart Regebro lrege...@jarn.com [2009-12-06 21:14]:
 Time had therefore come to zope.testing. Why
 zope.testing? Because most components in zope.* uses zc.buildout, and
 zc.buildouts tests uses zope.testing. But of course we here have a
 bootstrapping problem, zope.testing of course also uses buildout.

When I worked on py3 stuff on the DZUG sprint in September, we broke out
of that catch-22 by porting zope.testing first, and running its test
using http://pypi.python.org/pypi/discover, patched[1] to pick up
tests via the test_suite() methods. That way we could run the tests of
zope.testing under py3 without needing zope.testing itself or
zc.buildout to do so, so porting zope.testing could be tackled.

Our work from then is on the regebro-python3 branch (which might be
familiar ;-). I don't quite remember how far we've come. I *think* most
of the porting work is done and we were last working on integrating
Distribute/2to3 into the setup.py, but got hung up on the Distribute
side of things.

Wolfgang

[1]
@@ -54,9 +54,12 @@
 if isinstance(obj, type) and issubclass(obj, unittest.TestCase):
 tests.append(self.loadTestsFromTestCase(obj))
 
-load_tests = getattr(module, 'load_tests', None)
+load_tests = getattr(module, 'test_suite', None)
 if use_load_tests and load_tests is not None:
-return load_tests(self, tests, None)
+tests = load_tests()
+if not tests:
+return lambda x: None
+return tests
 return self.suiteClass(tests)

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


Re: [Zope-dev] Adapter for class with slots

2009-12-06 Thread Wolfgang Schnerring
* Shane Hathaway sh...@hathawaymix.org [2009-12-03 11:44]:
 Wolfgang Schnerring wrote:
 The minimal reproduction recipe to see the error is this:
 
 class Slotted(object):
 __slots__ = ('__provides__')
 
 zope.component.provideAdapter(
 lambda x: True, (Slotted,), zope.interface.Interface)
 
 Which will raise
   File 
 /home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
   line 419, in _getAdapterRequired
   elif not ISpecification.providedBy(r):
   TypeError: 'member_descriptor' object is not callable

 It looks to me like a possible bug in zope.interface.  Try deleting 
 _zope_interface_coptimizations.so to hopefully expand that traceback.

Thanks for the hint! This enabled me to step through all of it with pdb,
which turns up zope/interface/declarations.py:1249

  def getObjectSpecification(ob):
  provides = getattr(ob, '__provides__', None)
  if provides is not None:
  return provides
  [...]

So it seems that __provides__ is part of the zope.interface mechanics,
and if unset that attribute should not exist -- but when using __slots__
it always exists, namely as a 'member_descriptor' object.

I'll try and see whether I can come up with a way for zope.interface to
do the Right Thing(tm) in this situation.

Wolfgang

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


[Zope-dev] Adapter for class with slots

2009-12-03 Thread Wolfgang Schnerring
Hello,

I've stumbled upon a wrinkly edge case (bug?) in zope.component.

What I was trying to do is register an AbsoluteURL adapter for
lovely.remotetask.processor.ProcessorRequest objects, and since they
don't implement a specific interface, I thought I'd use the class
itself as the required component. But registering the adapter for 
* lovely.remotetask.processor.ProcessorRequest fails with a strange
TypeError (see below). The reason is that the class inherits from
zope.publisher.base.BaseRequests which uses __slots__.

The minimal reproduction recipe to see the error is this:

class Slotted(object):
__slots__ = ('__provides__')

zope.component.provideAdapter(
lambda x: True, (Slotted,), zope.interface.Interface)

Which will raise
  File 
/home/wosc/.python-eggs/zope.component-3.7.1-py2.6.egg/zope/component/registry.py,
  line 419, in _getAdapterRequired
  elif not ISpecification.providedBy(r):
  TypeError: 'member_descriptor' object is not callable

Why is this? Can this be made to work? How would I go about
investigating that?

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


Re: [Zope-dev] implementing zope.component 4.0

2009-11-29 Thread Wolfgang Schnerring
* Martijn Faassen faas...@startifact.com [2009-11-27 12:32]:
 Are people okay with the proposed semantics?

+1, I think making these disappear into the language as much as possible
is a Good Thing(tm).

 Would people be okay with such an upgrade path? Any better ideas?

Yes, I'm okay with it. I do think we should take care that the
transition period is long enough, so that people have a chance to update
their code. (The deprecation warnings proposed elsewhere should help
there, I think this is a good use case for them.) 
Thus, we should not start requiring zope.component 4.0 everywhere
immediately (because it's new, great and shiny ;), but rather use
3.9+future when we want to use the new semantics, and only after I don't
know, 6 months maybe, start switching over completely.

 Most importantly, any volunteers?

I'm interested, but I'm not sure whether I'll have free resources in the
near future. :-/

Wolfgang

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


Re: [Zope-dev] improving the utility and adapter lookup APIs

2009-11-25 Thread Wolfgang Schnerring
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
  What about a simple and consistent API for all components including
  utilities, adapters and multiadapters:
 
  IFoo()
  IFoo(x)
  IFoo(x, y)

I quite like the simplicity of this spelling, so I want to be sure
*why* it must be ruled out. (...or does it, really?)

I'm thinking that this...

* Martijn Faassen faas...@startifact.com [2009-11-25 22:21]:
 The last one won't work if we want to maintain backwards compatibility. 
 The second argument is the default.

is a valid argument, while this...

* Tres Seaver tsea...@palladion.com [2009-11-25 13:34]:
 You can't use an arbitrary number of positional arguments for the
 contexts, because we need to support the named / default cases too.

is not, as evidenced by...

* Fabio Tranchitella kob...@kobold.it [2009-11-25 20:51]:
 IFoo(x, y, default=None, name='something')

or am I missing something here?

So I'm thinking, there is no technical reason that prevents Thomas'
spelling, and I'm wondering, do we really have to preserve backwards
compatibility for this case?

Wolfgang
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-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] IRC discussion about testing

2009-08-13 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-12 20:56]:
 This seems heavier than needed.  Also, if someone extends this,
 they're going to get an awful lot of sections that might have names
 that conflict with names in their buildout.  I do like the fact that
 the versions section is reusable. :)

 Here's an alternative:

   [versions]
   zope.foo = 1.2.3
   zope.bar = 1.2.3
   zope.app.baz = 1.2.3
   grok.bar = 1.1.0
   thirdparty.dependency = 4.4

   [ztk]
   projects = zope.foo zope.bar zope.app.baz
   also-tested = grok.bar

Yup, that looks much better. As far as I'm concerned, let's use this.
(I'll leave it to Martijn to explain whether/which/why additional
information should be stored in the KGS in computer-readable form.)

I've just updated z3c.recipe.compattest to support exactly this:

   [buildout]
   parts = ztk-tests
   extends = the-file-above

   [ztk-tests]
   recipe = z3c.recipe.compattest
   include = ${ztk:projects} ${ztk:also-tested}

Would you give it a try?

Wolfgang

___
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] IRC discussion about testing

2009-08-12 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-12 01:36]:
 On Tue, Aug 11, 2009 at 5:22 PM, Jim Fultonj...@zope.com wrote:
 - The versions specified in the controlled-packages.cfg don't seem to
 be honored except for the package being tested. For example,
 ZODB3-3.9.0b2 is used for test-kgs-ZODB3, but 3.9.0b5 is used for
 everything else. Fortunately, it appears I can work around this
 using a buildout versions section.

 In playing with this today, I'm inclined to think that it would be
 simpler to use a list of packages in an option to specify the packages
 to be tested and used a versions section to specify versions, rather
 than using a controlled-packages configuration file.

This doesn't strike me as simpler to *use* (as I said earlier, I'd much
prefer a *single* gesture of use this KGS to set up both the versions
and the list of packages to run tests for, and I think it's worth
spending effort to get there), but I'm not sure that's what you meant.
What makes you prefer two files instead of one?

I'm quite willing to either merge the z3c.recipe.kgs into compattest or
abandon the latter (or whatever) and to write a buildout extension to
pin the versions using a controlled-packages file, but I only want to do
that kind of work if we're reasonably certain that this is what we want.

Wolfgang

___
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] IRC discussion about testing

2009-08-12 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-12 11:52]:
 On Wed, Aug 12, 2009 at 2:31 AM, Wolfgang Schnerringw...@gocept.com wrote:
* Jim Fulton j...@zope.com [2009-08-12 01:36]:
 In playing with this today, I'm inclined to think that it would be
 simpler to use a list of packages in an option to specify the packages
 to be tested and used a versions section to specify versions, rather
 than using a controlled-packages configuration file.

 This doesn't strike me as simpler to *use* (as I said earlier, I'd much
 prefer a *single* gesture of use this KGS to set up both the versions
 and the list of packages to run tests for, and I think it's worth
 spending effort to get there), but I'm not sure that's what you meant.
 What makes you prefer two files instead of one?

 I didn't say anything about 2 files.  I said I prefered a parts list
 in a single option in combination with a standard buildout versions
 section.

Sorry for my misunderstanding. In fact, I'm not hung up about the number
of files all that much, but rather I'm searching for a way not to
duplicate information. And that seems rather diffcult, since you
assert...

 - We'll need the versions section to consume the KGS.  That is, given
 a KGS, you'll often want to use the versions in other buildouts to
 limit them to the known good configuration.

...while Martijn said here 
http://article.gmane.org/gmane.comp.web.zope.devel/21328
that the KGS will need to store more information about each package than
a versions section can handle.

 - The parts section and versions section could be specified in a
 single file, so the gesture for using them could be pretty simple.

This seems to be the best we can do, given the above requirements.
If I understand you correctly, that file would then look something like this:

[versions]
zope.foo = 1.2.3
grok.bar = 1.1.0
thirdparty.dependency = 4.4

[zope.foo]
tested = true
kgs = ztk
develop = http://svn.zope.org/repos/main/zope.foo/branches/1.2

[grok.bar]
tested = true
develop = http://svn.zope.org/repos/main/grok.bar/trunk

[thirdparty.dependency]
tested = no

z3c.recipe.compattest/kgs would learn to extract all sections from the
above where tested=true. And zope.kgs/zope.release could then probably
be retired (or am I missing something?).

 - I think a parts list in an option will be easier to control.  For
 example, you will be able to use the standard buildout option
 incrementing and decrementating machinery to modify it.

I don't understand how a parts list could help here.

Wolfgang

___
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] KGS trunk without failures

2009-08-07 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-02 18:34]:
 2. Some of the tests only pass if run separately, due to test
 interactions. Presumably, this means that other tests aren't cleaning
 up after themselves.  I think we need a standard automated way to run
 each package's tests separately.  I think some folks are working on
 that.

I've just released z3c.recipe.compattest-0.6, which can now populate the
list of packages to run test for from a buildout section, which makes it
easy to test against a KGS. So, if you're developing zope.foo, you can
set up your buildout.cfg like this:

[buildout]
develop = .
parts = whatever else you need compat
extends = http://url/to/kgs/versions.cfg
# assuming said versions.cfg uses a section called [versions]:
versions = versions

[versions]
# use development version of our package
zope.foo =

[compat]
recipe = z3c.recipe.compattest

and then run bin/test-compat to run the tests of each package in
versions against the development version of zope.foo (in a separate process).

 So this means that if someone modifies a package that is in the KGS,
 they need to run the KGS tests before checking in.

After we reach a consensus on how to do it (I'm in favor of the way
outlined above, of course ;-), I'd like to add a step-by-step
walkthrough of the day-to-day development of a package somewhere below
http://docs.zope.org/zopetoolkit/process/index.html, which would
include a description of how to run KGS tests.

Regarding the KGS, I have a question: Where is the current KGS and how
do we update it?
By where is I mean the location of the versions.cfg,
by current I mean the trunk, the version currently in development,
the version where we probably want to bump the version number of a
package as soon as a version is released,
and by update I mean that I'd like this operation to involve no manual
interaction other than committing the new version number to SVN.

Wolfgang

___
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] KGS trunk without failures

2009-08-07 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-07 06:01]:
 How to do you specify the projects to be tested?  Does every project
 in versions get tested? If so, how do you specify versions for
 projects that you don't want to run tests for but do want to fix the
 version of.

With z3c.recipe.compattest, to build the list of projects to run tests
for you can at the moment:
- specify project names to include
- specify buildout section names whose keys will be included
(and it defaults to the [versions] section for ease of use)
- specify regexes to remove entries from the included list

So if your [versions] section contains projects you don't want to run
tests for, I guess you either need to exclude those explicitly, or not
feed this section to compattest in the first place and build up the
include list in a different way instead.

Could you elaborate what use case you are envisioning here?
 
Wolfgang
___
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] KGS trunk without failures

2009-08-07 Thread Wolfgang Schnerring
* Jim Fulton j...@zope.com [2009-08-07 12:39]:
 2009/8/7 Fabio Tranchitella kob...@kobold.it:
 * 2009-08-07 12:28, Jim Fulton wrote:
 How to do you specify the projects to be tested?  Does every project in
 versions get tested? If so, how do you specify versions for projects that
 you don't want to run tests for but do want to fix the version of.

 In my recipe, it automatically tests all the libraries that are marked as
 tested=true in the controlled-packages.cfg,

 Ah cool, so you don't just use the versions section.  Wolfgang?

My guideline was let's rely on buildout rather than let's use
zope.kgs or anything else rather specific.

Wolfgang

___
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] KGS trunk without failures

2009-08-07 Thread Wolfgang Schnerring
* Fabio Tranchitella kob...@kobold.it [2009-08-07 11:46]:
 * 2009-08-07 11:42, Wolfgang Schnerring wrote:
   
 http://svn.zope.org/*checkout*/zope.release/trunk/releases/controlled-packages.cfg
 IMHO the KGS testing should be done using the controlled-packages.cfg and
 not versions, because some of the packages in the KGS are marked as not to
 be tested.

If controlled-packages.cfg is to be the authoritative represenation of
the KGS (and maybe it should be, since it contains more information than
versions.cfg) then I'd probably wish for a buildout recipe that can pin
versions based on that data format, because I much prefer less moving
parts.

In other words, I would very much like a single gesture to tell buildout
use this KGS: extends=something-or-other.cfg. The rest should Just Work(tm).

- Less compiling. Having to explicitly regenerate versions.cfg feels
  superfluous
- While developing something, you probably want to change the KGS from
  the official one to a local one, having to remember to change both
  the versions.cfg and the packages.cfg for the compattests is error prone.

 Regarding the KGS, I have a question: Where is the current KGS and how
 do we update it? By where is I mean the location of the versions.cfg,

 AFAICK, It can be built from zope.release.

Right. But it's not publicly accessible. (And uploading to say
download.zope.org is restricted to people with access there)
But if versions.cfg is not to be the authoritative
representation of the KGS then my point here is moot.

Wolfgang

___
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.index 3.5.2 broken

2009-08-03 Thread Wolfgang Schnerring
* Andreas Jung li...@zopyx.com [2009-08-03 20:21]:
 On 03.08.09 20:15, Chris McDonough wrote:
 On 8/3/09 1:07 PM, Shane Hathaway wrote:
 Marius Gedminas wrote:
 On Sun, Aug 02, 2009 at 08:48:24PM +0200, Andreas Jung wrote:
 the doctests for zope.index 3.5.2 - as used in Zope 2.12  - fail badly:

 Python's string hashes return different valuesfor half of all the strings
 on 64-bit machines.  This influences the ordering of dictionary keys and
 some other things too (such as the sequence of random numbers you get if
 you use a string as the seed).

 Is there a buildbot for the zope.* or ZTK packages testing them under Linux
 32bit and 64 bit?

AFAICS all three buildbots listed on
http://docs.zope.org/zopetoolkit/process/tools.html do.

Wolfgang

___
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] List of packages in ZTK

2009-07-28 Thread Wolfgang Schnerring
* Wolfgang Schnerring w...@gocept.com [2009-07-23 08:32]:
 * Christian Theune c...@gocept.com [2009-07-04 13:33]:
 I took the Zope 3.4 KGS, removed the obvious packages that do not belong
 to the ZTK out of the list and created a home for the master list that
 defines which packages belong to the ZTK.
 http://docs.zope.org/zopetoolkit/about/packages.html

 The following packages say about themselves that they are deprecated, so
 I proprose moving them to the deprecated section in the package listing
 as well (I can do the editing if I get a go):

Silence is consent, isn't it? ;-) Commited in r102361.

Wolfgang

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


Re: [Zope-dev] [Checkins] SVN: zope.testing/trunk/ when a test module does not define a test_suite, first try to load any unittest.TestCase descendants in it before complaining it does not contain any

2009-07-24 Thread Wolfgang Schnerring
* Benji York be...@zope.com [2009-07-24 08:02]:
 On Fri, Jul 24, 2009 at 2:38 AM, Wolfgang Schnerringw...@wosc.de wrote:
  Log message for revision 102202:
   when a test module does not define a test_suite, first try to load
  any unittest.TestCase descendants in it before complaining it does not
  contain any tests
 
 I'd rather zope.testing support the test discovery protocol recently
 added to the Python standard library and backported as the discover
 module (http://pypi.python.org/pypi/discover).

When I proposed *this exact same* patch to Christian Theune one year
ago(!) he demurred with the comment along the lines of the testrunner
is up for refactoring and extensibility with regarding test discovery
anyway. One year later, nothing like that has happened AFAICS.

I'm quite done waiting, so I finally put this in as a stopgap that
removes the annoyance for 80% of the cases I know.

I'm glad to hear about that discovery protocol (didn't know about it
before), and I'm all for a proper solution (the registration of
doctests is another point to think about in this area), but I hope you
understand that I prefer a temporary fix (that will be replaced by
something proper later on) to *no fix at all*.

Wolfgang
___
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] List of packages in ZTK

2009-07-23 Thread Wolfgang Schnerring
* Christian Theune c...@gocept.com [2009-07-04 13:33]:
 I took the Zope 3.4 KGS, removed the obvious packages that do not belong
 to the ZTK out of the list and created a home for the master list that
 defines which packages belong to the ZTK.
 http://docs.zope.org/zopetoolkit/about/packages.html

 So, if you see that a package is missing or is classified in the wrong
 way, then please speak up.

The following packages say about themselves that they are deprecated, so
I proprose moving them to the deprecated section in the package listing
as well (I can do the editing if I get a go):

zope.modulealias
zope.thread
zope.app.annotation
zope.app.container
zope.app.folder
zope.app.layers
zope.app.skins
zope.app.pluggableauth
zope.app.session
zope.app.traversing
zope.app.workflow
zope.app.zapi
zope.app.intid
zope.app.keyreference

Wolfgang

___
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] How to test changes to ZTK packages?

2009-06-30 Thread Wolfgang Schnerring
* Tres Seaver tsea...@palladion.com [2009-06-30 20:41]:
 Jim Fulton wrote:
 I should know this, but I don't.  What is the recommended way to test  
 changes to core ZTK packages to mitigate the risk that changes affect  
 other packages? Is there a page somewhere with instructions?
 
 I tried using using zope.release.  Building the trunk of zope.release  
 with Python 2.4 and running the tests gives lots of test import errors  
 and test failures.  (Lots of tests want to import z3c.pt.) The tests  
 hang when I try to build and run with Python 2.6.

 There is a recipe for testing *other* packages which might be affected
 by changes to the package-under-development:
  http://pypi.python.org/pypi/z3c.recipe.compattest

This recipe was written at the Grok dependency-cleanup sprint in January
with exactly the purpose Jim talks about: testing packages against each
other to make sure changes in one don't adversely affect the others.

I haven't studied zope.release closely yet, but I think testing-wise it
does quite a similar thing, namely running tests for a set of packages.

The difference is that compattest uses either pinned version from
buildout (but doesn't supply its own list of pins), or alternatively
trunk checkouts. Also, it seems to be more lightweight than zope.release
both in concept and in usage (mostly since it only does one thing,
namely running tests, and not other release management stuff like
creating tarballs and uploading them etc.), but I'm biased since I'm one
of the compattest authors.

For the record, the usage is
1. add it to your buildout, minimally like so:
   [compattest]
   recipe = z3c.recipe.compattest
2. run bin/compattest
3. there is no step three. ;-)

 I don't know how to supply the set of dependents to that recipe
 (something in the buildout config file, I guess).

You can specify include and exclude options; the default is to include a
list of zope.* packages that we pulled out of thin air at the sprint,
it'd probably be better to use the KGS as a default instead -- but that
would duplicate even more zope.release functionality.

I think it would be useful to standardize on *one* compatibility testing
method for the ZTK (and then document it).

My instinct would be to separate KGS handling from tarball creation from
testing, that is, remove the test-business from zope.release and use the
compattest recipe instead. (Alternatively, retire compattest and have
zope.release gain the ability to use trunks so it could be used for
continuous integration purposes as well -- but that doesn't feel quite
right, to be honest)

Thoughts?

Wolfgang

___
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] Hg mirror available

2009-06-22 Thread Wolfgang Schnerring
Hello,

* Sidnei da Silva sidnei.da.si...@gmail.com [2009-06-19 14:26]:
 On Fri, Jun 19, 2009 at 2:43 AM, Wolfgang Schnerringw...@gocept.com wrote:
 $ svn log repos/project/trunk/feature.txt
 
 r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line

 merged feature1
 
 r8 | wosc | 2009-06-18 17:11:43 +0200 (Thu, 18 Jun 2009) | 1 line

 implemented feature1
 

 As you can see, Subversion reports the history of the file that
 happenened on the branch (in r8).

 Can you show us your 'svn --version'? I suspect what you're seeing is
 a result of svn 1.5 merge tracking.

I've dug a little deeper, and found that the example I presented is a
special case, since 'feature.txt' has been *added* on the branch, and
Subversion has indeed always treated the history of copied/added/removed
files differently.

You're right that in the general case, Subversion is only able to show
the whole history (including branches) using the 1.5-mergeinfo support.
One can invoke this via 'svn log --use-merge-history': on my example
repository, compare the output for project/trunk/foo.txt with and
without that switch; without it only shows the merge commit.

Hmm. This means that even if conversion tools did something useful with
the mergeinfo properties (which right now they don't), it would only
solve my specific problem of preserving history for the last 6-12 months
or so, since the repository I'm dealing with stems from 2003 or
something, meaning Subversion 1.2ish, which did not even *store* the
information necessary to recover the history.

I guess I'll need to think about this some more (and then move to a
different mailing list, as we're getting way off-topic for zope-dev ;-)

Thanks for your insights,
Wolfgang

___
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] Hg mirror available

2009-06-18 Thread Wolfgang Schnerring
* Sebastien Douche sdou...@gmail.com [2009-06-18 01:34]:
 This is a first attempt to build an Mercurial mirror :
 http://hg.zope.mirrors.securactive.org/

How did you convert the repository?

I'm asking because I noticed that basically all SVN-DVCS conversion
tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py,
svn-all-fast-export.cpp) do not convert the history properly, more
precisely, history that happened on branches is lost:

1. import /trunk/foo.txt
2. branch /trunk to /branches/mybranch
3. edit /mybranch/foo.txt
4. merge /mybranch to /trunk

If you now ask svn for the history of /trunk/foo.txt (say with 'svn
log'), you see both steps 3 and 4. After conversion to a DVCS with one
of the above mentioned tools, you only see step 4, while step 3 never
happened in the DVCS repository. I think that's unacceptable, most
importantly because all commit messages that happened on branches are
lost that way.

Does somebody here know something about this phenomenon, by any chance?
Am I missing something?

Wolfgang

___
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] Hg mirror available

2009-06-18 Thread Wolfgang Schnerring
Hi there,

* Sidnei da Silva sidnei.da.si...@gmail.com [2009-06-18 14:28]:
  I'm asking because I noticed that basically all SVN-DVCS conversion
  tools (hg convert, git-svn, bzr svn-import, svn2bzr, svn-fast-export.py,
  svn-all-fast-export.cpp) do not convert the history properly, more
  precisely, history that happened on branches is lost:
 
 Here's some context about this from one of the Bazaar developers, John
 Arbash Meinel. Hopefully that will solve some of your questions?

Thanks for relaying!
 
 I'm not really sure what he means by edit and then merge without a
 commit inbetween. So I'm assuming there is one.

Sorry for being overly brief in my description; please find below a
sample shell script to set up a Subversion repository with a project
containing a trunk and a branch. To reproduce the problem I'm
concerned about, do this:

$ create-repos.sh repos
$ svn log repos/project/trunk/feature.txt

r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line

merged feature1

r8 | wosc | 2009-06-18 17:11:43 +0200 (Thu, 18 Jun 2009) | 1 line

implemented feature1


As you can see, Subversion reports the history of the file that
happenened on the branch (in r8).

After converting the repository, however...

$ bzr init-repo repos-bzr
$ cd repos-bzr
$ bzr svn-import file://$PWD/../repos
$ bzr log repos/project/trunk/feature.txt

revno: 3
svn revno: 9 (on /project/trunk)
committer: wosc
timestamp: Thu 2009-06-18 14:11:46 +
message:
  merged feature1

... this history is lost. Not only does it not appear in the log
output, also when looking at bzr visualize it seems like that branch
never existed at all in bzr. (I'm new to bzr, am I missing something
here?)

 Now, what really matters is whether or not *Subversion* recorded 4
 correctly, such that it can actually see that it was a merge from 3.
 My understanding is that before svn 1.5 that isn't possible.

My understanding is quite different. ;-)
As far as I know, SVN always has recorded the history of a file
across copies and merges, and so I'm quite sure this has nothing to do
with 1.5-style merge tracking. I won't try to track down a reference
on that right now, but I'm currently reading up on SVN's APIs so I
expect to find the answer there, anyway.

 I'm pretty sure SVN represents (4) as not a *merge* but as an indentical
 commit.

As I said, I'm still digging through the SVN APIs, so unfortunately I
don't have a concrete answer, but I know positively that this history
information is readily available, which you can see by passing
--verbose to 'svn log':

$ svn log -v -c 9 repos

r9 | wosc | 2009-06-18 17:11:46 +0200 (Thu, 18 Jun 2009) | 1 line
Changed paths:
   M /project/trunk
   A /project/trunk/feature.txt (from /project/branches/feature1/feature.txt:8)
  ^
   M /project/trunk/foo.txt

merged feature1


Wolfgang


**

#!/bin/sh

if [ $# -lt 1 ]; then
  echo 12 Usage: $0 repos-path
  exit 1
fi

set -e

mkdir $1
repos=$(cd $1  pwd)
rmdir $1

working=$(tempfile)
rm $working
mkdir $working

svnadmin create $repos
svn mkdir file://$repos/project -m creating project home
svn mkdir file://$repos/project/trunk -m creating trunk
svn mkdir file://$repos/project/branches -m creating branches
svn mkdir file://$repos/project/tags -m creating tags
svn co file://$repos/project/trunk $working
cd $working

mkdir alpha
echo foo  foo.txt
echo bar  alpha/bar.txt
svn add foo.txt alpha
svn commit -m initial version

svn cp file://$repos/project/trunk file://$repos/project/tags/0.1 -m tagging 
0.1

svn cp file://$repos/project/trunk file://$repos/project/branches/feature1 -m 
creating branch 1
svn switch file://$repos/project/branches/feature1
echo qux  foo.txt
echo feature1  feature.txt
svn add feature.txt
svn commit -m implemented feature1

svn switch file://$repos/project/trunk
svn merge file://$repos/project/branches/feature1
svn commit -m merged feature1
svn rm file://$repos/project/branches/feature1 -m remove branch after merge

svn cp file://$repos/project/trunk file://$repos/project/tags/0.2 -m tagging 
0.2

svn cp file://$repos/project/trunk file://$repos/project/branches/feature2 -m 
creating branch 2
svn switch file://$repos/project/branches/feature2
echo feature2  feature.txt
svn commit -m implemented feature 2

rm -rf $working
___
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
 

Re: [Zope-dev] buildbots

2009-06-17 Thread Wolfgang Schnerring
* Sebastien Douche sdou...@gmail.com [2009-06-16 14:15]:
Hello,

 On Tue, Jun 16, 2009 at 08:00, Wolfgang Schnerring w...@gocept.com wrote:
 http://zope.buildbot.securactive.org/waterfall
 (the ZTK docs mention only the first two. Why?)
 Because nobody had this server on the list ;).

I've added it now. 8-)

 What I couldn't quite figure out, however is: what, exactly, do these
 buildbots test?
 1. checkout svn://svn.zope.org/repos/main/zope.release/trunk,

Ah. I didn't know about zope.release, I'll need to look at that. Thanks!

 If not, is there something I could do to help make that come true?
 I can't make this for all packages on SVN ; so what are the packages
 that you want?

I'll need to look into this further, but could you imagine adding
another builder, in addition to linux-kgs34 and linux-kgs35, let's say
linux-kgstrunk, if there was something like zope.release that this
builder could use?

Wolfgang

___
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] buildbots

2009-06-16 Thread Wolfgang Schnerring
Hello,

from various clippings of this list and the ZTK docs at
http://docs.zope.org/zopetoolkit/process/tools.html I've gathered
that there are (at least) three buildbot installations running tests
for the Zope Toolkit:

http://zope3.pov.lt/buildbot/waterfall
http://zope3.afpy.org/buildbot/waterfall
http://zope.buildbot.securactive.org/waterfall
(the ZTK docs mention only the first two. Why?)

This is great! I think that having continuous, automated test runs can
be very beneficial for spotting problems quickly (e. g. with
interoperability).

What I couldn't quite figure out, however is: what, exactly, do these
buildbots test?

I imagine one very useful scenario (don't know if there are others),
and that would be for each package X in the (still to be determined?)
list of ZTK packages, take its trunk (whenever that is updated) and
the trunks of all packages it depends on (only if those are ZTK
packages, of course, else use the according released version), and run
X's tests.

Is this covered by one of these buildbot installations? If not, is
there something I could do to help make that come true?

Thanks,
Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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] Bug tracking

2009-06-11 Thread Wolfgang Schnerring
Hello,

I'm trying to understand how we are using the bug tracker.

I noticed that on Launchpad right now there are both umbrella projects
such as Zope2 and Zope3, and individual projects such as
zope.app.form and zope.testing -- but the list of those
subprojects is very far from comprehensive.

I don't understand this duplication. If I fix a bug in, say,
zope.testing, I now have to mark it fixed twice, once for zope.testing
and once for Zope3, and I don't see how this gains us any information.

Shouldn't we rename Zope3 to Zope Toolkit and then fold the
various subprojects into that? (We could still use tags or something
like that if we need additional filtering capabilities)

Am I missing something here?

Wolfgang
___
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] ZTK scope (was: [Checkins] SVN: zope.app.publisher/trunk/)

2009-06-10 Thread Wolfgang Schnerring
Hello,

* Stephan Richter srich...@cosmos.phy.tufts.edu [2009-06-09 15:51]:
 On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
 To make browsers update their caches of resources immediately when the
 resource changes, the absolute URLs of resources can now be made to
 contain a hash of the resource's contents, so it will look like
 /++noop++12345/@@/myresource instead of /@@/myresource.

 Mmmh, this looks like a lot of extra code to get behavior that is served 
 better with different tools. Have you looked at z3c.versionedresource and 
 z3c.traverser? Both of those should solve these type of use cases well.

Hmm, it looks like z3c.versionedresource requires me to use a
non-standard way to retrieve a resource's URL, which is a major
requirement for me; and I must confess I'm not sure how z3c.traverser
would help me implement this functionality.

I do feel that this incident touches upon a quite important point, and that
is the scope of the Zope Toolkit. As I understand it, the ZTK wants to
provide support for developing web applications. To do that, I think it
should provide solutions to common problems in that area. Browser caches
and CSS/JS-files IMHO is a common problem that is well within the scope
of the ZTK, and so we should have a ready-to-use solution there.

But sure, this functionality can be moved outside of zope.app.publisher,
since with r100748 Resource uses IAbsoluteURL, which can be customized
externally, so I'll back out the change for the time being.

Wolfgang

___
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] Who uses request.getPositionalArguments()?

2009-06-09 Thread Wolfgang Schnerring
Hello,

I've stumbled over this by accident, but it seems that
getPositionalArguments() in zope.publisher.base.BaseRequest
always returns an empty value (at least, there are no tests in which
it has a non-empty value), and it is also not overridden by any of the
request subclasses in zope.publisher.

I still haven't quite wrapped my head around the whole publishing
machinery, but this strikes me as a little strange, nonetheless.

Could somebody enlighten me why this is so?

Thanks,
Wolfgang
___
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] Who uses request.getPositionalArguments()?

2009-06-09 Thread Wolfgang Schnerring
* Stephan Richter srich...@cosmos.phy.tufts.edu [2009-06-09 10:02]:
 On Tuesday 09 June 2009, Wolfgang Schnerring wrote:
  I've stumbled over this by accident, but it seems that
  getPositionalArguments() in zope.publisher.base.BaseRequest
  always returns an empty value (at least, there are no tests in which
  it has a non-empty value), and it is also not overridden by any of the
  request subclasses in zope.publisher.
 
 I think this may be a remnant of Zope 2's version of the publisher. The 
 method 
 should be used in mapply() to provide the correct arguments to the method to 
 be called at the end of traversal, but these days we usually do not implement 
 methods that expect any arguments, in fact the common case is this:
 
 class View(BrowserView):
 
   def __call__(self):
return ...

But even the case with arguments
def __call__(self, foo, bar):
is handled directly by mapply() (which does introspection and then
looks in the request for the names it found) -- which made
getPositionalArguments seem all the more superfluous to me...

Wolfgang
___
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] release zope.testing?

2009-06-05 Thread Wolfgang Schnerring
Hello,

I've recently fixed two bugs in zope.testing that I find annoying on
an almost daily basis (commandline option -1 doesn't work and readline
is broken in pdb).

Could someone review the changes on the trunk and cut a release of
zope.testing?

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


Re: [Zope-dev] zc.recipe.cmmi shared builds

2009-05-18 Thread Wolfgang Schnerring
* Fred Drake fdr...@gmail.com [2009-05-16 14:09]:
 On Tue, May 12, 2009 at 10:56 AM, Wolfgang Schnerring w...@gocept.com wrote:
 Looks good so far. Could someone do a release of zc.recipe.cmmi
 (or grant 'wosc' pypi access so I can do it myself)?

 Done.

Thanks! I've just cut the 1.2.0 release that includes the shared build
directory functionality.

Wolfgang

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


Re: [Zope-dev] zc.recipe.cmmi shared builds

2009-05-16 Thread Wolfgang Schnerring
* Wolfgang Schnerring w...@gocept.com [2009-03-24 16:01]:
 * Wolfgang Schnerring w...@gocept.com [2009-03-24 10:26]:
 I'd like to extend zc.recipe.cmmi to support shared build directories.

 Implemented in r98334. I'll use this locally over the next few days, and will
 then try to push out a release if it proves stable.

Looks good so far. Could someone do a release of zc.recipe.cmmi
(or grant 'wosc' pypi access so I can do it myself)?

Thanks,
Wolfgang

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


[Zope-dev] zc.recipe.cmmi shared builds

2009-03-24 Thread Wolfgang Schnerring
Hello,

I'd like to extend zc.recipe.cmmi to support shared build directories.

Use case example: we use lxml in a lot of our projects, which
currently means having to build libxml and libxslt over and over
again, since the buildout needs to be standalone and thus can't depend
on them being installed on the system. But while that's a necessity
for deployment, it's really annoying for development.

Plan of attack:
Introduce an option shared (defaults to False). If that is set,
a) calculate HASH as a hash of the recipe's current options (e. g.
configure parameters, environment variables)
b) perform the cmmi in ${buildout:download-cache}/cmmi/build/HASH,
if that directory is not present yet. (Probably needs a little thought
about how to differentiate between present and has a complete build
and present but we errored out)

Any thoughts?

Thanks,
Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zc.recipe.cmmi shared builds

2009-03-24 Thread Wolfgang Schnerring
* Wolfgang Schnerring w...@gocept.com [2009-03-24 10:26]:
 I'd like to extend zc.recipe.cmmi to support shared build directories.

Implemented in r98334. I'll use this locally over the next few days, and will
then try to push out a release if it proves stable.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development


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

2009-03-10 Thread Wolfgang Schnerring
* Roger Ineichen d...@projekt01.ch [2009-03-09 02:12]:
 The zope.container package was broken.
 I added a missing ComponentLookupError import.

Also, there was a typo in that conditional branch, it should have been
self.context, not just context. I guess that's what I got for not writing a test
in the first place when I updated that browserDefault()-method. Sorry...

We just (r97680) finally wrote the test and fixed the typo.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

___
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.publisher uses deprecated IView

2009-03-06 Thread Wolfgang Schnerring
Hello,

since Dan Korostelev commented on my 
https://bugs.launchpad.net/zope3/+bug/338136
saying I should take it to the mailing list, here goes:

zope.publisher.interfaces.browser.IBrowserView inherits from
zope.component.interfaces.IView, which actually is
zope.component.bbb.interfaces.IView -- marked as deprecated since
2004, but no pointer what the replacement should be.

What's going on here?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zc.selenium Zope2 support

2009-02-19 Thread Wolfgang Schnerring
Hello,

On http://svn.zope.org/zc.selenium/branches/wosc-zope2/
I've worked to make zc.selenium be usable in Zope2/Five.

There are two big changes, apart from having to sprinkle some
try/except imports and other small compatibility bits around:
1. Since Zope2 insists quite firmly on running in its own process, the
current way reporting of test results to the runner via a
thread-shared queue is not possible. Instead, I've integrated a small
HTTP serving part into the runner that the browser can POST the
results to. This should incur no additional overhead, since the
previous way was browser POSTs to zope-side view which puts the
results into the queue and now it's browser POSTs to runner-side
view which puts the results into the queue.
2. I moved from class-based resources to simply use views (for *),
since the Five/Zope2 machinery gave me lots of trouble that just
disappeared once I switched to views instead of trying to trick
resources into acting like views. I think for zc.selenium-users (who
inherit from pytest.Test or use the test:seleniumTest directive) the
change should be completely backward-compatible.

Could someone please review the branch and check what's missing for it
to be merged to the trunk?

Thanks,
Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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] z3c.form 2.0

2009-02-11 Thread Wolfgang Schnerring
Hello,

 On Tuesday 10 February 2009, Wolfgang Schnerring wrote:
  I'd like to introduce this to z3c.form as well (see attached patch). Would
  it be alright with you for me to commit this to trunk (to then go into the
  release)?
* Stephan Richter srich...@cosmos.phy.tufts.edu [2009-02-11 03:19]:
 Add a test and you can check it in. :-)

Of course. That was a bit sloppy of me ;-), but also I wanted to check
first whether there were any objections against the change in general.

* Dan Korostelev nad...@gmail.com [2009-02-11 14:21]:
 Also, please add a note to CHANGES.txt about that you changed the
 signature of SelectFieldWidget, as it breaks backward-compatibility.
 Or think a way to avoid that problem. :-)

I've put in some parameter munging to retain backwards compatibility.
And I've added a changelog entry to describe the feature. ;-)

Commited in r96460.

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
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] z3c.form 2.0

2009-02-10 Thread Wolfgang Schnerring
* Dan Korostelev nad...@gmail.com [2009-02-09 19:08]:
 Source support - Seems to work fine. I've checked that out in my
 sandbox instance with zc.sourcefactory's context-less and
 context-based sources.

I'd very much like to put in a little bit of flexibility when looking up widgets
for source-based fields: zope.formlib looks up the widget for an IChoice field
by requiring a multi-adapter for (field, field.source) instead of just the
field, thus allowing you to differentiate widgets for different kinds of
sources.

I'd like to introduce this to z3c.form as well (see attached patch). Would it be
alright with you for me to commit this to trunk (to then go into the release)?

Wolfgang

-- 
Wolfgang Schnerring · w...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development

Index: src/z3c/form/browser/select.py
===
--- src/z3c/form/browser/select.py	(revision 96293)
+++ src/z3c/form/browser/select.py	(working copy)
@@ -75,7 +75,18 @@
 
 @zope.component.adapter(zope.schema.interfaces.IChoice, interfaces.IFormLayer)
 @zope.interface.implementer(interfaces.IFieldWidget)
-def SelectFieldWidget(field, request):
+def ChoiceWidgetDispatcher(field, request):
+Dispatch widget for IChoice based also on its source.
+return zope.component.getMultiAdapter((field, field.vocabulary, request),
+  interfaces.IFieldWidget)
+
+
+# can change to ISource once vocabularies are deprecated
+...@zope.component.adapter(zope.schema.interfaces.IChoice,
+zope.schema.interfaces.IBaseVocabulary,
+interfaces.IFormLayer)
+...@zope.interface.implementer(interfaces.IFieldWidget)
+def SelectFieldWidget(field, source, request):
 IFieldWidget factory for SelectWidget.
 return FieldWidget(field, SelectWidget(request))
 
@@ -98,4 +109,4 @@
 @zope.interface.implementer(interfaces.IFieldWidget)
 def CollectionChoiceSelectFieldWidget(field, value_type, request):
 IFieldWidget factory for SelectWidget.
-return SelectFieldWidget(field, request)
+return SelectFieldWidget(field, None, request)
Index: src/z3c/form/browser/select.zcml
===
--- src/z3c/form/browser/select.zcml	(revision 96293)
+++ src/z3c/form/browser/select.zcml	(working copy)
@@ -11,6 +11,10 @@
   /class
 
   adapter
+  factory=.select.ChoiceWidgetDispatcher
+  /
+
+  adapter
   factory=.select.SelectFieldWidget
   /
 
Index: src/z3c/form/testing.py
===
--- src/z3c/form/testing.py	(revision 96293)
+++ src/z3c/form/testing.py	(working copy)
@@ -281,6 +281,7 @@
 IPageTemplate, name=interfaces.DISPLAY_MODE)
 
 # Select Widget
+zope.component.provideAdapter(select.ChoiceWidgetDispatcher)
 zope.component.provideAdapter(select.SelectFieldWidget)
 zope.component.provideAdapter(
 widget.WidgetTemplateFactory(getPath('select_input.pt'), 'text/html'),
___
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.app.container -- zope.container

2009-01-29 Thread Wolfgang Schnerring
Hello,

we are holding a mini sprint at Marijn Faassen's place this week with
the main goal of reducing dependencies between Zope packages.
One result of this effort is that now the non-ZMI parts of
zope.app.container have been factored out into zope.container, and
only the ZMI-related bits (zope.app.container.browser) and
zope.app.container.interfaces.IAdding remain there.
(Martijn Faassen just blogged a visually appealing explanation of why
this was a Good Thing(tm) to do.)

We did this refactoring in a backwards-compatible way, so all symbols
can still be imported from their old location, and there are no
deprecation warnings, either, but still -- zope.app.container is
deprecated as of now (except of course for the .browser and IAdding
parts).

We've combed through (most of) svn.zope.org and updated referencing
packages accordingly, but if you find something that we've missed (or
import from zope.app.container in your own packages), please update it
at your convenience.
(Christian Theune will be adding import checking functionality to
zope.testing's testrunner that can aid in detecting moved imports,
this might be helpful for finding such things.)

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