[Zope-dev] Re: Why is test.py silent by default
Tres Seaver wrote: The default usecase for running tests should be a developer making changes and running tests. In this case, silent mode is unhelpful; it gives no feedback until the very end of the run, which takes a **long** time for the whole Zope2 tree. The dots provided at verbosity level one are good feedback for the developer: they provide a clue about how many tests have run, and give some chance of deducing that the tests have hung. Unless somebody has a compelling counter-argument, I will check in a patch which makes verbosity level 1 (dots) the default value. People who want quiet mode can always pass '-q'. +1 Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Proposal] RFC2396 compatible traversal parameters
I really really wouldn't want to see added on top of the current Zope2 publisher. The Zope 2 publisher (and the various traversal mechanisms -- publisher, restrictedTraverse, TALES) should first be refactored to use Zope 3 mechanisms, and only after that is done should we consider adding the kind of feature you propose. Florent Dieter Maurer wrote: Title: RFC2396 compatible traversal parameters Version: 1.0 Last-Modified: 2005/10/23 Author: Dieter Maurer [EMAIL PROTECTED] Content-Type: text/x-rst Created: 23-October-2005 Abstract RFC2396 defines the overall uri structure. Hierachical uri schemes have a path component consisting of a sequence of path segments. Each path segment consists of a name and optionally a sequence of parameters separated by ``;``. This proposal describes how Zope's publishing component can be enhanced to support path segment parameters, herein called traversal parameters. Rationale = There are some important use cases that require information to be kept across successive requests. The most prominent ones are maintaining the session id as well as skin and language selection. We recently met more special ones: keeping tab activation and information about the authentication domain (for remote login). The currently available solutions store this information in: - the session - a cookie - the URL Session and cookie storage have the disadvantages that they do not play well with the browser's history function and that they can seriously confuse caching (mittigated a bit by appropriate 'vary' cache controls, but not solved). Furthermore, cookies might not be available for security reasons. URL storage does not suffer these disadvantages but currently requires the introduction of artificial path segments for the additional information and difficult traversal magic to prevent the artificial segments from interfering with the traversal process. Traversal parameters can solve this much more naturally than artificial path segments. Zope currently does not support traversal parameters. Usage types === Traversal parameters can have two kinds of uses: - controlling the traversal process itself - providing information for the whole request Skin selection belongs for example to the first kind, tab activation to the second one; language selection may belong to either of them. While it seems most natural to attach information for the whole request to the last path segment, it is much more practical to use some path segment further to the front as this information might be used automatically (without explicit URL construction) by relative uri references. Risks = Support for traversal parameters controlling the traversal process itself will inevitably require deeper changes in Zope's traversal implementation. As this implementation is already quite complex and supports many use cases, the new extension might break some of them. I will outline the special risks in the solution part. There might be clients not implementing RFC 2396. Such clients might support parameters only at the path end and view everything after the first ``;`` as part of the parameters. Such clients might resolve relative uri references incorrectly in the presence of traversal parameters. Proposed solution = The solution modifies Zope's ``ZPublisher.BaseRequest.BaseRequest.traverse``. Currently, the ``path`` argument is split into a sequence of names, maintained reversed in the ``TraversalRequestNameStack``. The solution splits it into a sequence of pairs, consisting of the name and the sequence of parameters. ``TraversalRequestNameStack`` will contain the name only when the parameter sequence is empty but the pair, otherwise. Usually, this will allow traversal magic (modification of ``TraversalRequestNameStack`` to change the traversal process) to continue to work as previously unless it hits a pair when it expects a name only. Such (hopefully rare) cases will break. When the traversal process has located a subobject, it checks whether it has a ``__traversal_parameter_process_hook__``. If so, it calls it with ``request`` and the parameter list as arguments. The method may change the list which will affect the parameters added to the constructed (URL) path segment. The traversal will maintain the parameters for the current step in ``TraversalRequestStepParameterList`` to make them available for ``__bobo_traverse__``. An aware ``__bobo_traverse__`` implementation might change this list affecting the parameters seen in further processing. To support parameters destined to the complete request (rather than individual traversal steps), all found parameters are collected in ``TraversalRequestCollectedParameterList``. Individual steps that want to modify the collected parameters can assign a new list to ``TraversalRequestStepCollectParameterList``. The original value is a reference to ``TraversalRequestStepParameterList``. Thus, if it is changed in
Re: [Zope-dev] Mountpoints
[Chris McDonough] There is a wrinkle about performing this merge that eluded my memory until now. To support multidatabases within Zope, it was reasonable to change ZODB.config.ZODBDatabase to support the heretofore likely-unused-by-real-world-code databases and database_name options that may now be passed into ZODB.DB's constructor: http://svn.zope.org/ZODB/branches/blob-merge-branch/src/ZODB/config.py?rev=38626r1=38574r2=38626 The current blob-merge-branch code depends on this change being available in the ZODB revision it uses. ... Chris, here's the current state: - The following is on current ZODB trunk, and on the new tag svn://svn.zope.org/repos/main/ZODB/tags/3.6.0b1 I suggest changing the zodb-blobs-branch to use that tag now (and merging that branch to Zope trunk when it's all happy again). - I added an optional new database_name key to zodb config. I understand that you may not want to use it in Zope 2.9, taking the database name from Zope's zodb_db section instead. That's fine. I expect that whatever name (however decided) should be used can be poked into config.database_name before calling ZODBDatabase.open(). Should check that the section name and database_name key aren't both specified? Probably, ya. - ZODBDatabase.open() has an optional new databases= argument, so that part's still exactly the same way you did it (except that I didn't add that argument to BaseConfig.open() too -- I don't think it belongs there, as BaseConfig is also a base class for classes whose open() overrides don't support a databases= argument; the ZODBDatabase subclass _extends_ BaseConfig's open() in this respect). Is there more I can do to help this along (or, perhaps, delay it more ;-))? If so, just ask. ___ 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] Mountpoints
Chris, FYI, I stitched ZODB 3.6.0b1 into zodb-blobs-branch, and changed ZopeDatabase.createDB() to plug database_name into config instead of passing it to ZODBDatabase.open(). The checkin msg summarizes test results; since I haven't work on this branch before, I'm not sure what was expected here (I didn't get a clean test run before stitching 3.6.0b1 in either): http://mail.zope.org/pipermail/zope-checkins/2005-October/029904.html How would you like to proceed? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: SVN: Zope/branches/zodb-blobs-branch/ Move to ZODB 3.6.0b1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: Log message for revision 39583: Move to ZODB 3.6.0b1. ZopeDatabase.createDB(): Plug database_name into config rather than passing it to ZODBDatabase.open(). More should be done to detect conflicting zodb_db section name and database_name, but I'm not sure where all the relevant code is. There are a number of DeprecationWarnings about subtransactions when running the tests. Should be repaired. One test failure, but doesn't look like it's related to ZODB: Nope. This one can be remediated by merging the fix on the current Five trunk: $ svn merge -r18808:18809 svn://codespeak.net/svn/z3/Five/trunk/ . Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDXTaC+gerLs4ltQ4RAqCsAJwNHqtn52MD6LI9b0XEbSK6g43jJQCfWP3w 2hHGKap4apmHmfi3XKWXd6o= =drIS -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: SVN: Zope/branches/zodb-blobs-branch/ Move to ZODB 3.6.0b1.
[Tim Peters] Log message for revision 39583: Move to ZODB 3.6.0b1. ZopeDatabase.createDB(): Plug database_name into config rather than passing it to ZODBDatabase.open(). More should be done to detect conflicting zodb_db section name and database_name, but I'm not sure where all the relevant code is. There are a number of DeprecationWarnings about subtransactions when running the tests. Should be repaired. One test failure, but doesn't look like it's related to ZODB: [Tres Seaver] Nope. This one can be remediated by merging the fix on the current Five trunk: $ svn merge -r18808:18809 svn://codespeak.net/svn/z3/Five/trunk/ . That one should go away by magic then when the branch is merged to the trunk (this test is passing on Zope trunk -- or doesn't exist anymore on Zope trunk -- or something ;-)). A number of deprecation warnings should go away by magic too (e.g., OFS/Image.py on Zope trunk no longer uses subtransactions). The bulk of the deprecation warnings are coming out of ZODB's own tests, most from testZODB.py. I'm still baffled by that, because they don't show up when running tests from a ZODB checkout, or when running the Zope3 test suite. testZODB.py is trying to stop them: # deprecated37 remove when subtransactions go away # Don't complain about subtxns in these tests. warnings.filterwarnings(ignore, .*\nsubtransactions are deprecated, DeprecationWarning, __name__) While that's been effective in ZODB and Zope3, for some reason it doesn't seem to accomplish anything in zodb-blobs-branch ... ___ 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] Mountpoints
Thanks for this! Looks like that test failure is incidental and not symptomatic of changes made to ZODB. I think Tres may have said that it can be fixed by merging in a fix from the Five HEAD, but I don't know this for fact first-hand. It's encouraging that most of the tests pass but there are a paucity of tests that specifically test Zope 2 multidatabase-based mount points. There are a few convincing-looking decoys in Products.ZODBMountPoint.tests but I think I'll need to create a few more to get the warm and fuzzies before doing the merge. I have this on my plate for Wednesday evening. - C On Oct 24, 2005, at 2:45 PM, Tim Peters wrote: Chris, FYI, I stitched ZODB 3.6.0b1 into zodb-blobs-branch, and changed ZopeDatabase.createDB() to plug database_name into config instead of passing it to ZODBDatabase.open(). The checkin msg summarizes test results; since I haven't work on this branch before, I'm not sure what was expected here (I didn't get a clean test run before stitching 3.6.0b1 in either): http://mail.zope.org/pipermail/zope-checkins/2005-October/ 029904.html How would you like to proceed? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [z3-five] Reintegrating Zope 3 (was Re: RFC: Five 1.2 and 1.3 release plan)
Jim Fulton wrote: I was about to start working on integrating the new test runner and was reminded that we need to integrate Zope differently than we did for 2.8/3.0. Then, we took advantage of the fact that packages not included in the Zope X3 3.0 release were trimmed from the corresponding branch. This didn't happen for 3.1 and isn't going to happen moving forward. For starters, I'm going to give Zope 2 it's own zope directory. (I'm also going to use the pkgutil mechanism: file:///home/jim/Documentation/Python-Docs-2.3.3/lib/module-pkgutil.html which was added for us. :) Then I'm going to use externals to get the packages we use, initially from whatever tag z2 is using now. OK, this is done. Unfortunately, because svn:externals is half baked, you'll need to remove your existing zope package before updating an existing sandbox. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] Mountpoints
[Chris McDonough] Thanks for this! Not required, so long as I get to thank you for finishing it ;-) Looks like that test failure is incidental and not symptomatic of changes made to ZODB. I think Tres may have said that it can be fixed by merging in a fix from the Five HEAD, but I don't know this for fact first-hand. I'm sure that failure will go away by itself when you're working on the trunk instead of the branch. What I'd do now: - Check out Zope trunk. - Merge the branch into your trunk sandbox, and forget the branch. - Fix merge conflicts. I got one, in datatypes.py, and I didn't know immediately what to do about it so stopped there. You'll have better luck ;-). Note that, under SVN, after you fix a conflict, you have to do svn resolved path/to/conflicted/file; that's a gimmick to make sure you don't forget about conflicts. - svn up to make sure you've got all the externals the merged files point at. - svn up from time to time thereafter, to suck in other trunk changes as they get made. - Check it in when it's stable. - If it takes longer than expected, make a _new_ branch _from_ your merged-into-trunk local trunk sandbox. (That's easy: make a branch directory, svn switch to it from your local merged trunk sandbox, and svn commit -- all done). It's encouraging that most of the tests pass but there are a paucity of tests that specifically test Zope 2 multidatabase-based mount points. There are a few convincing-looking decoys in Products.ZODBMountPoint.tests but I think I'll need to create a few more to get the warm and fuzzies before doing the merge. As above, you can do a _local_ merge right away. This would save you from other decoys (like the DeprecationWarnings that would no longer exist if you were using the trunk instead of the brach, and the failing-on-branch-but-not-trunk Five test). I recall that, historically, the Zope tests never failed when Zope mounting was in fact broken, so a fat +1 to beefing test coverage there. I have this on my plate for Wednesday evening. Understood; there really isn't any good TV on Wednesdays anymore ;-) ___ 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 )
