Re: [Zope-dev] [TIP] zope.testrunner and nose count doctests differently
On Wed, Nov 9, 2011 at 2:53 AM, Chris Withers ch...@simplistix.co.uk wrote: Hi Benji, On 08/11/2011 11:10, Jonathan Lange wrote: Mark has somewhat misdirected the thread here, either that or I've got in a muddle, anyway, the issue at hand is that nose ignores TestCase.countTestCases(). Any nose people know what that is? Not a nose person, but it's usual to report on TestResult.testsRun rather than TestSuite.countTestCases. The numbers can be different because one test might run multiple times or report multiple results, or tests might be generated during the run that weren't available for countTestCases to count. If this is the case, perhaps Manuel shouldn't do anything with countTestCases? (I know it would drop the test count, but that's not *that* important, right? ;-) - and at least all the test runners would agree...) Meh. Having a good count in complaint test runners is more important to me than having all test runners agree. Especially since the lowest common denominator seems to be counting the entire file as one test. PS: When are you going to move source control for Manuel over to GitHub? I have no plans to move the source. If I did I'd probably move it to launchpad.net because most of the other things I work on are there (including work things). -- Benji York ___ 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.testrunner and nose count doctests differently
On Thu, Nov 3, 2011 at 7:13 AM, Chris Withers ch...@simplistix.co.uk wrote: The code uses Manuel, under both nose and zope.testrunner: Manuel will report the same test count under both nose and zope.testrunner but I don't know if nose respects the count provided. You could put a breakpoint in TestCase.countTestCases() of manuel/testing.py and see if it gets called by nose and what it does with the result. If you will tell me how you wired up Manuel and nose, I'd love to add a how-to section to the Manuel docs. -- Benji York ___ 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?
On Wed, Oct 26, 2011 at 10:26 AM, Wolfgang Schnerring w...@gocept.com wrote: 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). 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). -- Benji York ___ 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] Raw search through entire Zope database?
On Wed, Oct 12, 2011 at 5:55 AM, li...@nidelven-it.no wrote: Is there some script that will enable a raw search through everything that is in the database and give a usable result? It's an API, not a script, but this might help: http://zodb.readthedocs.org/en/latest/api.html#ZODB.interfaces.IStorageCurrentRecordIteration -- Benji York ___ 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)
On Sun, Mar 27, 2011 at 10:54 AM, Uli Fouquet u...@gnufix.de wrote: - `assert` works like you would expect it to work in tests. No need to use `self.assertEqual()`` and friends (but you can if you prefer). How do they deal with the fact that assert statements are dropped when Python is run with -O? -- Benji York ___ 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: 109 OK, 24 Failed, 4 Unknown
On Wed, Mar 23, 2011 at 10:08 AM, Michael Howitz m...@gocept.com wrote: Am 23.03.2011 um 12:57 schrieb Zope Tests Summarizer: Test failures - [...] Subject: FAILED : Zope 3.4 Known Good Set / py2.4-32bit-linux From: buildbot at pov.lt Date: Tue Mar 22 22:26:52 EDT 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/035953.html While: Installing test. Getting distribution for 'ClientForm==0.2.9'. An internal error occured due to a bug in either zc.buildout or in a recipe being used: Traceback (most recent call last): ... File /var/lib/buildbot/slaves/zope-kgs/py2.4-32bit-linux/build/test/eggs/setuptools-0.6c11-py2.4.egg/setuptools/package_index.py, line 553, in _download_to size = int(headers[Content-Length]) ValueError: invalid literal for int(): 102936, 102936 Buildout tries to download ClientForm from sourceforge.net and seems to get a broken content-length header. I see the same problem when using distutils 0.6.14 since the last 3 or 4 days. But when I use wget the header seems to be correct or wget is smart enough to fix it. Both pip install and wget work here. Here are the headers wget retrieves: % wget -S http://wwwsearch.sourceforge.net/old/ClientForm/src/ClientForm-0.2.9.tar.gz --2011-03-23 10:17:20-- http://wwwsearch.sourceforge.net/old/ClientForm/src/ClientForm-0.2.9.tar.gz Resolving wwwsearch.sourceforge.net... 216.34.181.96 Connecting to wwwsearch.sourceforge.net|216.34.181.96|:80... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Server: Apache/2.2.3 (CentOS) Last-Modified: Sat, 19 Jul 2008 13:29:12 GMT ETag: 19218-4526075b55a00 Content-Length: 102936 Expires: Fri, 25 Mar 2011 14:17:12 GMT Content-Type: application/x-gzip Content-Length: 102936 Date: Wed, 23 Mar 2011 14:17:12 GMT X-Varnish: 74437985 Age: 0 Via: 1.1 varnish Connection: keep-alive Length: 102936 (101K) [application/x-gzip] Saving to: `ClientForm-0.2.9.tar.gz' -- Benji York ___ 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)
On Tue, Feb 1, 2011 at 3:32 AM, Wolfgang Schnerring w...@gocept.com wrote: 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. +1 Compatibility is key. Note however that it's also harder than it looks, so gratuitous change will often bite you. That being said, I think you're on the right track here. -- Benji York ___ 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] Manuel and TestFixtures
On Fri, Jan 14, 2011 at 7:42 AM, Chris Withers ch...@simplistix.co.uk wrote: http://packages.python.org/testfixtures/files.html#using-with-manuel Very cool. -- Benji York ___ 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
On Wed, Dec 15, 2010 at 8:06 AM, Brian Sutherland br...@vanguardistas.net wrote: I've committed a WebTest integration with testbrowser to a jinty-webtest branch. It basically uses WebTest as a backend to drive a WSGI application. This sounds like a nice improvement over using wsgi-intercept (http://code.google.com/p/wsgi-intercept/). I've taken a quick look at the branch. I saw a few of these in the diff: - from zope.testbrowser.testing import Browser +XXX: what to do with this? +XXX from zope.testbrowser.testing import Browser If you can give me some background maybe I can help with these. The copyright date in src/zope/testbrowser/wsgi.py needs the current year. I suspect large chunks of zope.testbrowser.wsgi can be eliminated with judicious refactoring. If you want, I should have time to review your branch again before you merge it. -- Benji York ___ 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] Context priority as an alternative to configuration directive overrides
On Thu, Dec 2, 2010 at 3:15 AM, Malthe Borch mbo...@gmail.com wrote: I always found configuration overrides (e.g. ZCML's includeOverrides directive) to be difficult to manage and hard to get right. How about an alternative where you can put a priority on a configuration context like so: adapter zcml:priority=100 ... / I appreciate the flexibility inherent in that approach, but personally, I'd be frightened of such a system. I sometimes have problems figuring out which directives are active in the current system, if I had to reason about dozens of priority levels I think it'd be worse. If accompagnied by a sane amount of logging output, this system might facilitate plugging in components for the rest of us. I don't quite follow the for the rest of us part. Will you expand on that? -- Benji York ___ 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] Draft of new aggregator
On Wed, Dec 1, 2010 at 3:04 AM, Jens Vagelpohl j...@dataflake.org wrote: If I understood Christian right he wants to keep the full list of entries sorted so everyone knows where to find their items of interest quickly. I think that's valuable, the full list should stay as it is. +1 Perhaps even a blank line between groups would help accentuate the groupings. -- Benji York ___ 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.testrunner 4.0 release
On Tue, Oct 19, 2010 at 5:34 AM, Jan-Jaap Driessen jdries...@thehealthagency.com wrote: You two worked on zope.testrunner trunk most recently. Tests pass on all platforms [1] Do you think zope.testrunner is ready for a 4.0 release? +1 I've been using b2 on some small projects for a while without issues and I looked over the bugs in Launchpad for it and didn't see anything that seems like a release blocker. -- Benji York ___ 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] ZEO TempStorage: Odd behavior on ZEO restart
On Wed, Jul 14, 2010 at 6:59 PM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On Wed, Jul 14, 2010 at 19:22, Benji York be...@benjiyork.com wrote: [...] Not surprising really. What could be surprising is that, since the objects are not in the object cache or the ZEO cache, how can the clients 'know' about them to request them? And the answer is probably that there are other objects which ARE in the object cache, or the ZEO cache and that hold references (ghost objects in the case of the object-cache) to the objects in the zeo-distributed temporary storage. Indeed. My jet lag ate that part of the story. Thanks. So, perhaps, Sebastian can avoid a Zope restart if he finds a way to flush all caches. Flushing the object caches is easy, it's in the Control_Panel. Flushing the ZEO cache is something else. Perhaps he can run with a 0-sized ZEO cache for the TempStorages? If this were me, I'd use a non-temporary storage and implement an expiry policy for the results cache. The bforest package would be a good start (http://pypi.python.org/pypi/zope.bforest). In fact, I would expect they already have an expiry policy in place, so they might be able to just start using a non-temporary storage right away. -- Benji York ___ 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] ZEO TempStorage: Odd behavior on ZEO restart
On Sun, Jul 11, 2010 at 1:41 AM, Sebastian Tiedtke s...@mdvtts.com wrote: We're working on a large scale Plone deployment and recently came across some odd behavior with tempstorage at our ZEO server. The system setup consists of a central ZEO server that provides the storage for content as well as a temp storage for sessioning. There are multiple other servers that run multiple Plone instances with ZEO clients. Let me make sure I understand your setup: you have a TemporaryStorage running on a central server that is exposed via ZEO to clients. Right? So, when the ZEO server restarts the temp storage is reset (it's contents don't survive a restart by design), but the clients don't know all the objects they know about in the temp storage just disappeared. Therefore when they go to load one (because it wasn't in their object or ZEO caches), the load fails. Not surprising really. -- Benji York ___ 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: 42 OK, 3 Failed
On Tue, Jun 29, 2010 at 3:18 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zope Tests Summarizer wrote: Summary of messages to the zope-tests list. Period Sun Jun 27 12:00:00 2010 UTC to Mon Jun 28 12:00:00 2010 UTC. There were 45 messages: 6 from Zope Tests, 11 from ccomb at free.fr, 1 from ct at gocept.com, 27 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : Zope Buildbot / zope2.12 slave-osx From: jdriessen at thehealthagency.com Date: Sun Jun 27 13:01:37 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015850.html The failing test here looks completely absurd: - --- % --- Failure in test /Users/buildslave/.buildout/eggs/zope.testbrowser-3.6.0a2-py2.6.egg/zope/testbrowser/README.txt Failed doctest test for README.txt File /Users/buildslave/.buildout/eggs/zope.testbrowser-3.6.0a2-py2.6.egg/zope/testbrowser/README.txt, line 0 - -- File /Users/buildslave/.buildout/eggs/zope.testbrowser-3.6.0a2-py2.6.egg/zope/testbrowser/README.txt, line 1248, in README.txt Failed example: browser.lastRequestPystones 1 # really big number for safety Expected: True Got: False - --- % --- What in the name of all that is holy is that supposed to be testing (much lest documenting)? In other words: who wants to argue for not ripping that useless (so I assert ;) assertion out? The above is attempting to document the fact that the lastRequestPystones exists and is a number. If I were to write the test today I'd use a mocking framework to fix the number returned so the example is more direct, but it seems sufficient as-is. -- Benji York ___ 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: 42 OK, 3 Failed
On Thu, Jul 1, 2010 at 11:34 AM, Tres Seaver tsea...@palladion.com wrote: The fact that the test failed seems to make it less than sufficient. I don't quite see how checking pystones is a useful measure, unless you *know* that there is only CPU involved and that the machine where you are checking it is effectively unloaded: I/O and scheduling latencies aren't going to be magically subtracted. Is this a complaint about the test/documentation or the feature? If the test/documentation, I've already stated what should be done about it -- and I may do so at some point in the near future. In the meantime, adding another zero or five would decrease the chance of it failing again. If the feature: it's certainly not perfect, but has been useful. -- Benji York ___ 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: Proposed new style for documenting and testing ZTK packages
On Mon, Apr 19, 2010 at 7:21 AM, Charlie Clark charlie.cl...@clark-consulting.eu wrote: Narrative documentation forces you to explain yourself to someone else. Neither, however, will necessarily notice if you forget something: tests aren't documentation and docu [sic] Quite true. It is also true that tests should be well documented and documentation should be well tested. Some prefer doctests for both. -- Benji York ___ 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: Proposed new style for documenting and testing ZTK packages
On Mon, Apr 19, 2010 at 9:48 AM, Marius Gedminas mar...@gedmin.as wrote: On Mon, Apr 19, 2010 at 12:50:23PM +0200, Adam GROSZER wrote: I'm somewhat vary on unittests. I've seen some damn cryptic ones that took a lot of time to decipher. A doctest somehow forces you to dump your mind (well at least that, if we're not that brilliant techdoc writers). That's true, but if the doctest gets too long, any readability advantages are negated. If you've the discipline to keep the doctests short, I don't see why you shouldn't continue writing them instead of unit tests -- and by short I mean 1-7 statements: You might be interested in Manuel's isolation mechanism: http://packages.python.org/manuel/#test-isolation The downside of this style is that it's difficult to refactor common bits from the doctests into shared methods, so you end up with a lot of duplicated code. If I understand you (which I'm not sure I do), I prefer to factor out common code into test helpers that are either referenced in footnotes (to keep all the code in one place) or in a separate module. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
On Fri, Apr 9, 2010 at 10:57 AM, Fred Drake fdr...@gmail.com wrote: I think the *right* thing to do is update the copyrights to reflect the copyright ownership, but not to otherwise change package metadata. +1 -- Benji York ___ 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)
On Wed, Mar 31, 2010 at 11:16 AM, Christian Theune c...@gocept.com wrote: 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. +1 for summaries. At a minimum they make me feel like a bad person for not participating more. ;) -- Benji York ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland br...@vanguardistas.net wrote: On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component. I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional. Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort. -- Benji York ___ 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 11:34 AM, Brian Sutherland br...@vanguardistas.net wrote: On Thu, Mar 04, 2010 at 11:19:52AM -0500, Benji York wrote: On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland br...@vanguardistas.net wrote: On Thu, Mar 04, 2010 at 10:09:26AM -0500, Jim Fulton wrote: In the specific case of zope.event, I'd prefer it stay separate. I want developers to be able to publish events without having to commit to a subscription mechanism. For example, ZODB depends on zope.event so it can generate events and provide a generic hook mechanism. I don't want it to depend on zope.component. I just committed a jinty-optional-event branch for zope.component that's an experiment as to how to make the dependency on zope.event optional. Maybe I'm missing something, but zope.event is so minimal I can't see that making optional is worth the effort. Actually, I misunderstood your question. Good, because while reading you're response I was so confused I worried that I had recently had a stroke and not realized it yet. -- Benji York ___ 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] Adding W3C validating to zope.testbrowser
On Tue, Feb 23, 2010 at 9:57 AM, Marius Gedminas mar...@gedmin.as wrote: I'd like to chime in and suggest using WSGI to hook up zope.testbrowser and zope.app.testing.functional (or a better-designed replacement for the latter). Then you could plug in W3CValidatingMiddleware (if one doesn't exist, it should be trivial to write it) between them. +1 The ability to plug in testing code into the WSGI pipeline the same way we plug in production code into a WSGI server pipeline sounds cool. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing 3.8.7: downgrade the deprecation warning
On Tue, Jan 26, 2010 at 7:49 AM, Marius Gedminas mar...@gedmin.as wrote: Any ideas about fixing the deprecation warning caused by renormalizing.py? All it does is 'import doctest' which, due to Python's unfortunate import semantics, is interpreted as 'from zope.testing import doctest' Ideas? It's not real pretty, but you can do absolute imports in Python 2.4 like so: import imp name = 'doctest' doctest = imp.load_module(name, *imp.find_module(name)) Manuel uses this technique to import doctest (Manuel also has a submodule named doctest). -- Benji York ___ 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] windows newslines in doctests
Manuel 1.0.3 -- available on PyPI -- opens files in universal newline mode. I hope that fixes your newline problem -- Benji York ___ 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] small manuel bugfix
On Fri, Dec 25, 2009 at 9:37 PM, Chris McDonough chr...@plope.com wrote: I added a branch of manuel to the Zope SVN that fixes the codeblock plugin when you use codeblock roles such as: I've released Manuel 1.0.3 which includes this fix. -- Benji York ___ 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] patterns for using sphinx with the Zope Toolkit?
On Sat, Jan 2, 2010 at 8:44 PM, Chris McDonough chr...@plope.com wrote: Python samples in Sphinx docs are generated like so: .. code-block:: python a == 1 I did a bit of fooling around with Manuel, because I wanted to make sure that the code blocks in my documentation actually worked, but I wound up in a place where I use Manuel to check only the *syntax* of a subets of the Sphinx code blocks I use. It will do this right out of the box if you read the Manuel docs But I couldn't really figure out a way to do the moral equivalent of this: .. code-block:: python a == 1 .. manuel-expect: True Sphinx and Manuel both support interpreter blocks, so the normal approach will work: a == 1 True Occasionally you want to show some code but hide the assertions about the effects of the code. You can do that by putting the tests in a reST comment after the code. .. code-block:: python a = Foo() b = a.bar() .. make sure the above worked correctly b.baz 42 -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 7:45 AM, Marius Gedminas mar...@gedmin.as wrote: On Wed, Dec 30, 2009 at 08:58:52AM +0100, Lennart Regebro wrote: On Tue, Dec 29, 2009 at 23:47, Marius Gedminas mar...@gedmin.as wrote: * support for the INTERPRET_FOOTNOTES feature Then they should use Manuel. Good, so we have a migration path for this bit! How mechanical can such a transformation be? The transformation should be reasonably mechanical. Something like this (untested): m = manuel.footnote.Manuel() m += manuel.doctest.Manuel(**kw) return manuel.testing.TestSuite(m, 'foo.txt') -- Benji York ___ 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] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 4:48 PM, Lennart Regebro rege...@gmail.com wrote:
On Sun, Jan 3, 2010 at 22:08, Benji York be...@zope.com wrote:
Occasionally you want to show some code but hide the assertions about
the effects of the code. You can do that by putting the tests in a reST
comment after the code.
.. code-block:: python
a = Foo()
b = a.bar()
.. make sure the above worked correctly
b.baz
42
That doesn't work for code that will raise an exception.
Also, if you want to both run a command and make sure it's output is
correct, then you need to do that twice.
In both of those cases normal doctest blocks seem appropriate.
Calling foo with the wrong parameters raises an exception:
foo('wrong')
Traceback (most recent call last):
...
ValueError: bad parameters
Calling the hello function prints a greeting.
hello()
Hello world!
--
Benji York
___
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] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:53 AM, Martijn Faassen faas...@startifact.com wrote: Lennart Regebro wrote: [snip] Also if the above code is deemed as being a Good Idea, I will remove all the usage of zope.testing.doctest from Manuel. This is necessary, as one of the things I need from Manuel is a Python 3 port, and I'm not porting zope.testing.doctest to Python 3. I think this is quite independently from the above the consensus anyway, right? Switching over from zope.testing.doctest to plain doctest anywhere seems like a good idea. Manuel uses the standard library's doctest almost exclusively. The only place zope.testing.doctest is used is to be compatible with zope.testing's expectations. I just took a stab at removing all references to zope.testing.doctest from Manuel and got it to work using the zope.testing trunk (Manuel needs DocTestFailureException). -- Benji York ___ 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] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:43 PM, Chris McDonough chr...@plope.com wrote:
Yeah. I haven't thought about this much, so it might be bollocks, but I
think something like this is what I'm after:
.. code-block-setup::
import sys
from somepackage.testing import DummyModule
sys.modules['models'] = DummyModule()
.. code-block:: python
:linenos:
from models import MyModel
from repoze.bfg.view import bfg_view
from repoze.bfg.chameleon_zpt import render_template_to_response
@bfg_view(name='my_view', request_method='POST', context=MyModel,
permission='read')
def my_view(request):
return {'a':1}
.. code-block-teardown::
del sys.modules['models']
Only the code-block would show up. Actually being a code-block would be
helpful, too, so we could use the other features of code-blocks, like line
numbers. Or something.
If you replace .. code-block-setup:: and .. code-block-teardown::
with .. invisible-code-block:: python you can do that with Manuel now
(http://packages.python.org/manuel/#invisible-code-blocks).
--
Benji York
___
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] windows newslines in doctests
On Tue, Dec 29, 2009 at 2:15 PM, Chris Withers ch...@simplistix.co.uk wrote: Fred Drake wrote: It's interesting to note that Python 2.6's doctest doesn't use universal newlines, but zope.testing.doctest. Interestingly, the doctests I referred to in my original post were Manuel doctests, which (Benji, lemme know if I'm wrong...) use Python's doctest module rather than zope.testing's one, in which case I think you may have hit the nail precisely on the head... Manuel uses Python's doctest module for the actual work, but the file reading is done by Manuel itself. I could switch to using universal new line mode, but since I haven't seen an example of a filing test I can't be sure if it'll help or not. -- Benji York ___ 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] small manuel bugfix
On Fri, Dec 25, 2009 at 10:31 PM, Chris McDonough chr...@plope.com wrote: Yeah. I'm a fan of unit tests. Yep, me too. To be clear, I do want unit tests in the form of a doctest (like http://svn.zope.org/manuel/trunk/src/manuel/bugs.txt?view=markup). Which may be the best place for this test. Thanks. -- Benji York ___ 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] small manuel bugfix
On Fri, Dec 25, 2009 at 9:37 PM, Chris McDonough chr...@plope.com wrote: I added a branch of manuel to the Zope SVN that fixes the codeblock plugin when you use codeblock roles such as: Looks good. Add tests and I'll merge and release your branch. I'm not sure what form the tests should take. There's probably no need to reflect this in the documentation, so non-documentation flavored tests are appropriate. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing feature creep in release (WAS: zope.testing.doctestunit and BBB)
On Wed, Dec 23, 2009 at 4:58 AM, Christian Theune c...@gocept.com wrote: Nevertheless, I think the (agile, many, flexible, easy) releases and not branching the trunk at all start hurting us here as we're getting lost in our own policy. Any ideas for limiting feature creep? Two comments: Whenever I wish I had created a major release branch (like /branches/1.5) at that point I go back and create one by copying the 1.5.0 tag. That way you have the best of both worlds, you don't have to remember to create major release branches (that you may never use) and you can have them if you end up doing significant maintenance on that version. As for having a broken trunk: I believe that every project needs a head maintainer that feels personally responsible for the state of a particular project. They would be in charge of reviewing and approving branches before they are merged to the project trunk. We've inherited a communal process from the pre-explosion days that worked well there, but there are just too many projects for the community to keep track of and to care for. -- Benji York ___ 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] windows newslines in doctests
On Mon, Dec 14, 2009 at 9:02 AM, Chris Withers ch...@simplistix.co.uk wrote: I've run into problems with Windows newlines in doctests a couple of times now and so thought I'd ask what people do in general to work around this... I don't think line ending problems happen very often. I'd be interested in seeing a doctest that has problems. Do you: ... - something else I'm not aware of :-) Maybe NORMALIZE_WHITESPACE would help. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZCA proposal
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway sh...@hathawaymix.org wrote: To me, myobj.get(x) reads as myobj, please get x and give me the result, so IFoo.adapt(y) reads as IFoo, please adapt y and give me the result. That statement makes perfect sense to me. Agreed. I also like adapt because it is a verb -- which I prefer method names to be. For the same reason I'm not real keen on the name utility... although I can't come up with anything better than get_utility at the moment. Too bad less-than is already defined for interfaces, otherwise we could do something crazy like IFoocontext for single adapters and IFooa, b, c for multiapdapters. I suppose we could do: IFoocontext and IFooa, b, c instead. Somehow I suspect that'll provoke a gag reflex in the most Pythonic among us as well as annoy those that want something googlable for the uninformed code reader. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Thu, Dec 3, 2009 at 9:43 AM, Marius Gedminas mar...@gedmin.as wrote: I've had some success with this: [snip code] Nice. I'd love to see this wired into the testrunner so people could specify breakpoints on the command line while running tests. If no one else gets around to that, I might. One day. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson m...@rpatterson.net wrote: I'm sorry, I was unclear, the try/finally clauses are not necessarily in *test tearDown* methods (though I used that language), they are often a part of the application being tested, such as closing the request, closing DB connections, or aborting transactions. In those situations I just edit the code and put a import pdb;pdb.set_trace() at the top of the finally: block and re-run the test. It is an interesting idea to provide some way to make that automatic. Maybe a settrace hook that will invoke pdb at the top of every finally clause that is encountered, somewhat similar to the -D option. You might end up getting way too many false positives though. Here's another idea: a testrunner option that takes a file name and line number and inserts a breakpoint at that position. That way you can get the same effect as editing the code without actually having to do so. -- Benji York ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 5:06 PM, Marius Gedminas mar...@gedmin.as wrote: On Wed, Dec 02, 2009 at 01:36:37PM -0500, Benji York wrote: Here's another idea: a testrunner option that takes a file name and line number and inserts a breakpoint at that position. That way you can get the same effect as editing the code without actually having to do so. Is that possible? I once spent hours studying pdb docs and found no way to set a breakpoint in advance, without modifying the source file in question, and without having the user to do manual interaction at the beginning. I was envisioning using sys.settrace() to set a trace function that would notice when the desired line of code is being executed and then trigger pdb. I didn't plan on pdb doing the breakpoint handling itself. -- Benji York ___ 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] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman wich...@wiggy.net wrote: On 2009-11-26 08:43, Michael Howitz wrote: Am 25.11.2009 um 15:49 schrieb Chris Withers: [...] Yes, PyPI is broken if you're an admin of many packages, feel free to me too on this issue: http://sourceforge.net/tracker/?func=detailaid=2793544group_id=66150atid=513503 It's fixed since yesterday. That's not a fix, it just replaced one problem with another one: it is now impossible to get your full list of packages. I've submitted a patch that removes the truncation behavior and makes the list scroll instead. Feel free to +1 the issue if you feel so moved: https://sourceforge.net/tracker/?func=detailaid=2906878group_id=66150atid=513503 -- Benji York ___ 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
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes matt...@matthewwilkes.co.uk wrote: On 2009-11-25, at 1601, Benji York wrote: I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) While this would be a multi-adapter lookup: IFoo(my_tuple) -- Benji York ___ 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] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman wich...@wiggy.net wrote: That's not a fix, it just replaced one problem with another one: it is now impossible to get your full list of packages. Indeed. Once SourceForge is allowing logins again I suggest we discuss this there. I'll be suggesting that the recent fix be reverted and they instead use the CSS I posted earlier. -- Benji York ___ 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] Zope3 server with SIGSEGV - what to do?
On Thu, Nov 26, 2009 at 6:52 AM, Hermann Himmelbauer du...@qwer.tk wrote: If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. Thanks a lot for help, that would really great. The question is, how do I find out (with my limited knowledge of zope.security) if the bug exists in 3.4.1? From looking at the code, it seems the bug does exist in 3.4.1 (and 3.4.2). I merged the fix to the 3.4 branch and released 3.4.3. I saw in your link you sent me that a core-dump can be made somehow, how can this be done? Because via that core-dump I expect we can pinpoint the reason and confirm the bug for zope.security-3.4.1? As a first step, I suggest putting 3.4.3 in production and seeing if the segfaults stop. -- Benji York ___ 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
On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida leoroch...@gmail.com wrote: On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote: On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes I know it's probably a spurious use case, but what if I want to adapt a tuple? There could be an optional keyword argument to be explicit. This would be a single-adapter lookup: IFoo(from=my_tuple) You probably already realized it by now, but this is a syntax error (remember: from module import name). Nope, it hadn't occurred to me. Some other argument name could be used instead. While this would be a multi-adapter lookup: IFoo(my_tuple) To take my stab at this bikeshed painting, and since it doesn't seem likely we'd want to break backward compatibility, I think I'd prefer the other way around: IFoo(multi=my_tuple) and leave the first parameter for single adaptation, although what I'd really prefer is multi-adaptation on multiple positional parameter. I'd rather have the common case (of adapting a non-tuple) be the simpler form and the exception (adapting a tuple) require more verbiage. -- Benji York ___ 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] Zope3 server with SIGSEGV - what to do?
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer du...@qwer.tk wrote: Ah, thanks that could be. My current version is zope.security-3.4.1 (as from KGS-3.4.0). The real bad thing about this is that it seems I'm stuck with that release as trying to upgrade to zope.security-3.7.1 fails due to dependencies. So I'd have to upgrade all packages (btw., there seems not to be any current KGS?). Yep. The introduction of so many non-backward-compatible changes in the last few years has also caused me great pain. Any ideas how to solve this? If this bug did indeed exist in 3.4.1, we can backport the fix and do a 3.4.x bug-fix release. -- Benji York ___ 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] Releasing zope.browserresource
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze t...@gocept.com wrote:
Argh, now the PyPI UI is really broken for me... No, seriously - thank you
very much.
If you're a GreaseMonkey user, try this:
// turn off (potentially) long list of projects
GM_addStyle('div#document-navigation {overflow: scroll; max-height:
15em; width: 15em; overflow-x: hidden}');
--
Benji York
___
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
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: [snip good stuff] Multiadapter: IFoo.multi(x, y) I'm not sure I like the following suggestion better than the above, but throwing it out there anyway: Multiadapter: IFoo((x,y)) Multiadapter with default: IFoo.multi(x, y, default=default) Expanding the above: IFoo((x,y), default=default) Utility: IFoo.utility() [or possibly IFoo() instead?] I like IFoo(). As a final thought, I don't like having to import 'implements' from zope.interface either. Since we're moving to Python 2.6 which supports class decorators, I'd like to see something like this become possible: @IFoo.implements class Foo(object): pass We already have the function decorator zope.interface.implementer, I'd extend that notion: @IFoo.implementer class Foo(object): pass If we do well we might all have this for Christmas. :) /me pens a letter to Zanta Claus. -- Benji York ___ 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] make zope.component.registry.Components inherit from dict?
On Tue, Nov 24, 2009 at 6:22 AM, Chris McDonough chr...@plope.com wrote: I think we have to divorce the requirement from the ZCA. The requirement: - an attribute of an instance of the class zope.component.registry.Components which is dictionarylike (accepts any key type, any value type). As far as I can tell you don't want any of the ZCA functionality (named utilities, overriding, etc.), so divorcing this from the ZCA seems appropriate. I still don't quite see why a module global dictionary doesn't meet your needs. -- Benji York ___ 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] Zope3 server with SIGSEGV - what to do?
On Tue, Nov 24, 2009 at 4:04 PM, Hermann Himmelbauer du...@qwer.tk wrote: This occurs once in a while, so it seems something segfaults and the server seems to notice that and restarts. Any clue what to do about this? If you're using a version of zope.security less than 3.7.1, I would suspect https://bugs.launchpad.net/zope3/+bug/181833. -- Benji York ___ 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] Testrunner option for running tests in random order?!?
On Fri, Oct 9, 2009 at 8:51 AM, Jonathan Ballet jonathan.bal...@securactive.net wrote: If I want this option to have an optional value, I think I must set a default value to the option. But then, how to make the distinction between the two first cases? I might miss something I don't know in option parsing, but I didn't find anything... I'd try the same approach as default options in Python functions. Make the default None (which isn't a valid seed) and then you can tell the difference. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Removing zope.testrecorder from the ZTK
On Wed, Oct 7, 2009 at 1:26 PM, Thomas Lotze t...@gocept.com wrote: I just noticed that zope.testrecorder, which is listed in ztk.cfg as an included package, imports from Globals, OFS, AccessControl and Products.PageTemplates. This looks to me as if zope.testrecorder shouldn't actually be part of the ZTK. It's also not used by any package mentioned in ztk.cfg. As one of the last few people to touch zope.testrecorder I should probably speak up with some background. The package was created several years ago to experiment with writing a browser test recorder that could output either testbrowser tests or old-style functional tests. It fell into disuse from almost the start but Philipp brought it out of mothballs to cover in his book. Since then I don't know that anyone has worked on it -- or that it works at all, in fact. I don't have any problem with it being dropped from the ZTK. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: Determining packages which are in the ZTK
On Mon, Sep 21, 2009 at 1:52 PM, Martijn Faassen faas...@startifact.com wrote: I agree we shouldn't make this harder. We should look into documenting the approach bobo uses in the ZTK documentation so people have some ideas on how to approach this. The Manuel docs themselves are also good examples of using Manuel: Rendered as HTML at http://packages.python.org/manuel/ Source at http://svn.zope.org/*checkout*/manuel/trunk/src/index.txt -- Benji York Senior Software Engineer Zope Corporation ___ 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] official release policy ZTK is still not changed
On Tue, Sep 15, 2009 at 4:56 PM, Tres Seaver tsea...@palladion.com wrote: I *like* the property of the 0 strategy that it makes the job of releasing a package a little harder: releaseing software should be a thoughtful, careful process, not something you do without a bit of hesitation and review. Well said. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 2:20 AM, Wichert Akkerman wich...@wiggy.net wrote: Suppose you are working on an app which includes a package that depends on A = 2.1 to make sure it can use a new API introduced in A 2.1. If you then add a develop egg for A to do some work on it things break with this policy because it will have version 0 and can no longer satisfy the = 2.1 requirement. Gotcha. Yep that's a down side of the zero approach. For me the scale still tips to using zero as the trunk version. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 9:07 AM, Marius Gedminas mar...@gedmin.as wrote: On Thu, Sep 10, 2009 at 04:23:31PM -0400, Benji York wrote: 3) [no] superfluous version bumps on the trunk I don't understand this one. Could you elaborate? The current practice is that after doing a release you have to change the trunk version to the next release number (a version bump). - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. That's nice. I think I tried to use [versions] my-dev-package = Yeah, it'd be nice if buildout allowed that or some other syntax (like my-dev-package = *). -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. Absolutely. This is that discussion. :) In addition, if you are going to release to pypi, there are tools like zest.releaser which make doing a release in the official way a snap (version-bump and all). That's good to know. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster gary.pos...@gmail.com wrote: Also, since I'm also in the setup.py should be able to specify minimum versions camp (admittedly unlike others, such as Benji, to my continued surprise) I've gotta keep you guessing somehow. ;) The '0' pattern seems like a loss for me, and at best a minimal win for those that are arguing for it. I'd prefer not to see a change, with the usual associated costs of communication and check-in police. Given the way the ZTK policies have shaped up I think I have to agree that zero on the trunk will probably be a small loss for most people working on ZTK projects. For the way I develop non-ZTK software the zeros are a small win. Luckily most of the software I develop isn't in the ZTK, so I'm fine with the status quo. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:41 AM, Martijn Faassen faas...@startifact.com wrote: Benji York wrote: On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen faas...@startifact.com wrote: Well, the official policy of the ZTK is still to use the 'dev' approach. We can't just suddenly start to use something else just like that, without discussion. Absolutely. This is that discussion. :) It's good we're having it now, but I'd much prefer to have one in advance. Alex's change was a simple mistake. He works with packages that use both styles. There wasn't any subversive intent. -- Benji York Senior Software Engineer Zope Corporation ___ 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] official release policy ZTK is still not changed
On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton j...@zope.com wrote: On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen faas...@startifact.com wrote: * I (and others) use tools to do releases (zest.releaser in my case). These tools are based on this policy. Changing the policy breaks the tools. The proposed change would make this tool simpler. More importantly, it makes things simpler for people who don't use the tool. +1 -- reducing the number of tools necessary to (easily) accomplish a particular task is valuable. -- Benji York Senior Software Engineer Zope Corporation ___ 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] writing and checking files with Manuel [PS]
On Tue, Sep 8, 2009 at 1:08 PM, Chris Withers ch...@simplistix.co.uk wrote: Chris Withers wrote: What I'd really like to do is write a Manuel plugin that will be part of testfixtures' [1] TempDirectory and would handle the following: Aside from looking at manuel.capture, can you give me any pointers as to what I'd need to write to make all the above happen? ...in particular, handling the case where the '::' is there as well as the case when it's not. manuel.capture does both, other than looking at it, I can't think of anything else to add. Oh, and I guess I need to worry about dedenting the text before I write it or use it for comparison. Any ideas? I would; manuel.capture does. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting ha...@hannosch.eu wrote: On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapmanachap...@zope.com wrote: Log message for revision 103721: keep trunk version at 0. Update changes I think I've seen the practice of denoting the version on trunk as zero from Jim already. It is in conflict with http://docs.zope.org/zopetoolkit/process/releasing-software.html though. The majority of packages still uses the version='3.4.2dev' scheme for trunk or branches. Pointing to the next release to be made with a dev marker. Are there any particular reasons, why this policy should be changed? I like 0 for two reasons: 1) it doesn't require predicting what the next release will be, 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Three, I like it for three reasons: 3) so superfluous version bumps on the trunk Amongst the reasons I like it are that: - when using a checkout as a develop egg you don't have to worry about finding out the exact version used on the trunk, you can always just use 0. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman wich...@wiggy.net wrote: On 2009-9-10 22:23, Benji York wrote: 2) if you accidentally make a trunk release no one will accedentally use it because it will be the oldest release on PyPI instead of the newest, Doesn't it break all versioned dependencies on that package? I don't understand the question, so I'll say no. ;) -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theunec...@gocept.com wrote: On 09/09/2009 05:05 PM, Martijn Faassen wrote: * better merge tracking For some interpretation of better. My team tried pretty hard to use 1.5's merge tracking and we could never get it to work well for us. The only advantage we ended up seeing was that we could freshen a branch from a trunk easily. Even that didn't buy us much because we previously had been using the relatively easy approach of rebranching from the trunkand merging from the stale branch to the new, fresh branch. The limitation of only being able to merge a feature branch back to the trunk once was also quite irritating. Plus the merge info properties constantly polluted svn diff and svn stat output as well as our commit email (the latter is fixable of course). After trying for a few months we abandoned it. YMMV. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] How to update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
On Fri, Aug 14, 2009 at 1:20 PM, Jim Fultonj...@zope.com wrote: On Fri, Aug 14, 2009 at 1:03 PM, Chris Withersch...@simplistix.co.uk wrote: ... One question, and I know I'm late in on this so feel free to point me at previous discussions, but say the KGS uses some.egg 1.0.0, a bug gets fixed in some.egg and 1.0.1 is released. Does a whole new KGS need to be cut or is there some process for testing and supporting, says, 1.0.0 = some.egg 1.1.0 ? The KGS should not support ranges IMO. It should be updated as new versions are released. It should also be tagged when updated. +1 We need to agree on the the process for updating the ZTK KGS. Here's a rough sketch of what I think we need. The outlined approach sounds good to me. It will give us the opportunity to run tests on all supported platforms before changes hit the trunk of a particular package. - When a developer wants to update a project version, they check out the test branch, make a local version change and run the tests. If the tests pass the check the change into the test branch. There is the minor concern that the test and trunk branches will get out of sync. - We maintain windows and linux buildbots (or equivalent) against both the test branch and trunk for Python 2.4, 2.5 and 2.6. I assume we'd have OS X buildbots as well (if someone will volunteer them). - When buildbot tests pass on all platforms and Python versions, we merge tested changes to the trunk. Note that the buildbot output needs to record the svn revision # tested. By buildbot output do you mean simply the fact that all tests passed on all platforms? -- Benji York Senior Software Engineer Zope Corporation ___ 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 update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
On Fri, Aug 14, 2009 at 2:13 PM, Jim Fultonj...@zope.com wrote: On Fri, Aug 14, 2009 at 1:58 PM, Benji Yorkbe...@zope.com wrote: By buildbot output do you mean simply the fact that all tests passed on all platforms? I'm being intentionally vague, but we need to know that the tests apply to the versions we're thinking of merging. At a minimum, the individual run outputs should contain the svn revision #. So, when merging changes, we make sure that the test branch changes being merged have been tested. I hesitate to suggest this (because it sounds like more work when we don't have enough volunteer's as-is), but how about if each branch had its tests run each time there was a commit made to it. That way we don't have to worry about mixing up changes in a single test branch and we'd also be able to tell -- by looking at the buildbot output for a particular branch -- if a branch that was being considered for merging to the trunk is actually passing on all platforms (OS and Python versions). I imagine that functionality would also be helpful to people developing on a branch. They could know if their changes cause tests to fail on platforms they might not have access to. -- Benji York Senior Software Engineer Zope Corporation ___ 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 update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
On Fri, Aug 14, 2009 at 2:51 PM, Jim Fultonj...@zope.com wrote: Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for? The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind. Beyond that there could be policies to take advantage of the infrastructure. A good policy might be that development is done on branches (as much development is done now) and a branch shouldn't be merged to the trunk unless all the tests pass (on all platforms). -- Benji York Senior Software Engineer Zope Corporation ___ 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 update the ZTK KGS (was Re: Working KGS tool! (was Re: IRC discussion about testing))
On Fri, Aug 14, 2009 at 3:05 PM, Jim Fultonj...@zope.com wrote: On Fri, Aug 14, 2009 at 2:58 PM, Benji Yorkbe...@zope.com wrote: On Fri, Aug 14, 2009 at 2:51 PM, Jim Fultonj...@zope.com wrote: Keep in mind that the thing we're talking about is pretty simple, basically a single file. Branches beyond a test branch seem like overkill. Maybe I missunderstand you. What sorts of branches did you have in mind? Do you imagibe long-standing branches that there'd be bots for? The idea would be that we have a buildbot that will run the tests for any branch when a commit is made to that branch. That's the entire infrastructure I had in mind. Hm, that seems a bit to clever to me. There might be lots of checkins on branches before someone is ready to update the KGS. shrug Buildbots are machines, they can do lots of repetitive work without complaining. Beyond that there could be policies to take advantage of the infrastructure. A good policy might be that development is done on branches (as much development is done now) and a branch shouldn't be merged to the trunk unless all the tests pass (on all platforms). That seems pretty intrusive to me. I assume this would only apply to packages in the ZTK. That's what I was thinking. I think I'd rather decouple management of individual projects from management of the KGS. I wonder what other people think. That's a reasonable stance. -- Benji York Senior Software Engineer Zope Corporation ___ 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
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). -- Benji York Senior Software Engineer Zope Corporation ___ 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] test setup layer sorting
On Mon, Jul 13, 2009 at 5:55 AM, Marius Gedminasmar...@gedmin.as wrote: Personally I would much prefer for the unit test layer to be sorted first. It is already treated specially by zope.testing; I see no harm in hardcoding its sort order. +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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.html with FCKEditor security fix
Version 1.2.0 of zope.html has just been released. It includes the security fix release of FCKEditor (2.6.4.1) which addresses http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-2265. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Manuel Beta
I've just released the first beta of Manuel, my next-generation doctest project. Being that zope-dev has some of the most well-informed users of doctest (and some of the most well-informed non-users of doctest), I'd like to gather feedback from this group before making an announcement to the wider world. Manuel is available from PyPI (http://pypi.python.org/pypi/manuel) with docs, details, and examples at http://packages.python.org/manuel/. I'm interested in any feedback and/or questions you may have be it technical, documentation, or marketing (i.e., how do I describe what Manuel does and what benefits it has). -- Benji York Senior Software Engineer Zope Corporation ___ 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] Manuel Beta
On Wed, Jun 24, 2009 at 5:06 PM, Chris Withersch...@simplistix.co.uk wrote:
One thing you may have solved already, but if not would make a fantastic
addition is a plugin that writes matching sections to a file.
So, rather than having the following in a doctest:
f = open(os.path.join('mytempdir','myfile.zcml'),'w')
f.write('''
configure xmlns=http://namespaces.zope.org/zope;
blah blah blah
/configure
'''.strip())
f.close()
zope.configuration.xmlconfig.file(join('mytempdir','myfile.zxml'))
I could have:
.. file:: myfile.zcml
configure xmlns=http://namespaces.zope.org/zope;
blah blah blah
/configure
There's no super-nice way to do exactly that, but here's a pretty
reasonable version:
--- begin quote ---
Contents of myfile.zcml::
configure xmlns=http://namespaces.zope.org/zope;
blah blah blah
/configure
.. - config
import tmpfile
f = tmpfile.mkstemp()
f.write(config)
f.close()
zope.configuration.xmlconfig.string(config)
--- end quote ---
Or, a much nicer version that doesn't use a temporary file (note the
change from .file to .string) in the code:
--- begin quote ---
Contents of myfile.zcml::
configure xmlns=http://namespaces.zope.org/zope;
blah blah blah
/configure
.. - config
zope.configuration.xmlconfig.string(config)
--- end quote ---
...with bonus points for telling me how to get this to render nicely with
Sphinx into a box with the file contents in it and a caption of the file
name :-)
The contents will be in a box, but the file name would be up to you to
describe in prose (as shown).
I could imagine a plug-in that understood the Sphinx
.. literalinclude:: example.file directive and made the included
lines available in a variable. That might be handy when you *really*
want to keep a file on-disk but still include part or all of it in a
document.
--
Benji York
Senior Software Engineer
Zope Corporation
___
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] Manuel Beta
On Wed, Jun 24, 2009 at 12:59 PM, Sebastien Douchesdou...@gmail.com wrote: 1. good idea for manuel.isolation, because it's for us a the main lack of doctests. But why this functionality is in a documentation package? Manuel, like doctest, is both for documentation and testing. I believe manuel.isolation is useful in both contexts. ...or I misunderstood what you meant by But why this functionality is in a 'documentation' package?. 2. we use intensely z3c.testsetup[1], can you explain how use manuel with it? I've only glanced at z3c.testsetup so I don't know how to use it with Manuel at the moment. I'll look and see if there's a good way to do so. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Manuel Beta
On Wed, Jun 24, 2009 at 6:07 PM, Chris Withersch...@simplistix.co.uk wrote: Benji York wrote: --- begin quote --- Contents of myfile.zcml:: configure xmlns=http://namespaces.zope.org/zope; blah blah blah /configure .. - config import tmpfile f = tmpfile.mkstemp() f.write(config) f.close() Okay, but this looks like I'd have to write the above every time I wanted to save a file As given, you are correct. A helper function could be written to shorten it to something like this: --- begin quote --- Contents of myfile.zcml:: configure xmlns=http://namespaces.zope.org/zope; blah blah blah /configure .. - config file_name = temp_file_helper(config) zope.configuration.xmlconfig.file(file_name) --- end quote --- *and* the saving code would show in the docs, or am I missing something? No, the code wouldn't be visible. The four lines of code after .. - config are in a reST comment (.. introduces a comment block). In fact, thinking about it, it'd be great if there were two plugins: - one to write files that code being tested could access from disk I think the version above with the helper does a reasonable job for this use case. - one to read files that code being tested had output and check their contents were as expected. I'd do that with something like this: --- begin quote --- Contents of myfile.zcml:: configure xmlns=http://namespaces.zope.org/zope; blah blah blah /configure .. - config file, file_name = make_a_named_temp_file() generate_a_file(fn) file.read() == config True --- end quote --- Alternatively, you might make a purpose-built Manuel plug-in to do exactly what you want. Maybe with syntax like... --- begin quote --- Contents of myfile.zcml:: configure xmlns=http://namespaces.zope.org/zope; blah blah blah /configure .. verify-file: name_of_function_to_do_verification --- end quote --- Where name_of_function_to_do_verification would be passed the file name (extracted from the line before the literal block) and the contents of the literal block. Your plug-in could provide a formatter that would show you a nice diff if there is a discrepancy. The code in manuel.capture would be a good starting point for something like that. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] tabs in the source
On Mon, Jun 22, 2009 at 1:16 PM, Adam GROSZERagros...@gmail.com wrote: Hello, Maybe it's time for an svn commit police squad? /me readies the tear gas. -- Benji York Senior Software Engineer Zope Corporation ___ 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.app.publisher/trunk/ To make browsers update their caches of resources immediately when the
On Wed, Jun 10, 2009 at 3:51 AM, Christian Zagrodnickc...@gocept.com wrote: The checkin actually is two in one (which aruably is not such a good thing): 1. Make resources compute urls with an IAbsoluteURL adapter so they behave like every other object. 2. Provide an optional hashing adapter (and the ++noop++ namespace). I'd actually separate number 2 into 2a (hashing adapter) and 2b (++noop++ namespace). I don't think we have to argue about 1. Agreed. The ++noop++ and hashing could easily be moved to a different package. I'd like to use the ++noop++ functionality separately from the hash calculating URL generation. The idea behind the hasing is that one should not have to think about new versions or cache invalidations. That's also why in development mode the hash is computed every time and not just once: It aids development a lot. But it helps in deployment as well of course. In my apps, I'll likely store a unique ID for each resource, or even use (a variation of) the app's version number for resources. That's why I'd like to use the ++noop++ namespace without the URL generation policy. So, why in a zope package? Because I really think this is a core issue of a web framework. Do we really want to not change any zope.* package any more in regard to new features? It is a core issue, but I'm not sure we've decided how to handle it yet. I'd rather the community try a few things and see if one dominant approach emerges. If so, it can be promoted to the zope namespace. Or not, there's no reason all widely used packages have to be in zope.*. -- Benji York Senior Software Engineer Zope Corporation ___ 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.app.publisher/trunk/ To makebrowsers update their caches of resources immediately when the
On Tue, Jun 9, 2009 at 10:50 AM, Roger Ineichend...@projekt01.ch wrote: anyway, I whould be happy if we do not implement such high level feature in zope core packages. Because there are 1000 different concepts to do it right. Why did you not use an additional package? I like the idea of ++noop++, but would also like to see it in a z3c (or similar) package. -- Benji York Senior Software Engineer Zope Corporation ___ 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] dropping Python 2.4 support in the Zope Toolkit?
On Tue, May 5, 2009 at 1:03 PM, Hermann Himmelbauer du...@qwer.tk wrote: Am Dienstag 05 Mai 2009 16:46:03 schrieb Martijn Faassen: Hey, Martijn Faassen wrote: Martijn Faassen wrote: In order to get to a conclusion: I haven't seen convincing arguments yet *not* to drop the Python 2.4 for new releases of the Zope Toolkit libraries. I'd like to phrase the debate in those terms instead of the reverse, because ensuring Python 2.4 compatibility is an additional burden for developers and we need good arguments for *not* dropping this burden. Since I haven't seen such arguments besides the Plone 3.x related ones, I will amend the zope toolkit decisions about this. A few more arguments popped up since then, as I half expected, so I'll remove that decision and re-open the discussion for a while. I don't want to upset a whole lot of Plone folks. Hmmm, maybe I'll come up with my suggestion publicly: If I understood the problem right, one main reason for dropping Python 2.4 is some error in .tar.gz compression. That was the trigger, but not the primary reason. I personally still somehow miss strong arguments for dropping Python 2.4 (except for the above bug). The motivators seem to be: - 2.4 is old (it's more than 3.5 years old, people want to use new features) - no further bug fix releases will be made for it (the fact that a major bug was introduced in 2.4.5 with no hope of it ever being fixed) - including 2.4 we have to support 3 major versions Python Most people seem to be moving to 2.5 or 2.6 and we (the community) don't have a good infrastructure to support 2.4, 2.5, and 2.6 on each of the platforms we want. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testing broken!
2009/5/2 Adam GROSZER agros...@gmail.com: Buildout was plagued also by this, solution is easy see svn://svn.zope.org/repos/main/zc.buildout/trunk r98303 I've made an annalogous change to the trunk of zope.testing, but I don't have a Windows box to test this on. It would be great if someone can confirm the fix. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Release management proposal
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net wrote: I want to suggest two changes to the standard release process: 1. use sdist --formats=zip. This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use. The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users. 2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py. Is there something zc.buildout or setuptools can do differently that will mitigate this? -- Benji York Senior Software Engineer Zope Corporation ___ 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] Release management proposal
On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman wich...@wiggy.net wrote: Previously Benji York wrote: On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman wich...@wiggy.net wrote: I want to suggest two changes to the standard release process: 1. use sdist --formats=zip. This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use. The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users. It was introduced in the last release of 2.4. As far as I know there are no plans to make a new 2.4 point release. That is most unfortunate. Maybe we should officially drop 2.4 support instead. -- Benji York Senior Software Engineer Zope Corporation ___ 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.javascript license question
On Fri, Apr 17, 2009 at 3:48 PM, Tres Seaver tsea...@palladion.com wrote: I think I recall that Jim ripped out an integration package for the Ext Javascript framework precisely because the licensing for Ext was initially questionable, and later became outright unacceptable. Yep, you recall correctly. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Zope 3.
On Thu, Apr 16, 2009 at 12:06 AM, Gary Poster gary.pos...@gmail.com wrote: This message seems like a reasonable start to me: Zope 3 has become focused on supporting frameworks and applications, rather than trying to be one itself. It is now called the Zope Toolkit. Parts of it are used by Zope 2, Plone, Grok, Repoze.bfg, and by many other different applications and frameworks. +lots I don't think trying to guess which parts or packages will die is a particularly useful exercise. Indeed. -- Benji York Senior Software Engineer Zope Corporation ___ 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] naming Zope
On Wed, Apr 8, 2009 at 11:54 AM, Shane Hathaway sh...@hathawaymix.org wrote: Martijn Faassen wrote: If we don't call Zope Framework 4.0, we'll be fine. We should call its first release 1.0 and there's no implication of a progression. +1 on calling it Zope Framework 1.0. We need the people who have been burned by past Zope releases to take another look, because we believe Zope is finally getting simpler. Those people would assume Zope-anything 4.0 is just piling on more complexity, while a version 1.0 release would invalidate that assumption and suggest they take another look. Maybe I'm dense, but from the description of the Zope Framework (from http://docs.zope.org/zopeframework/about/index.html) as a collection of libraries managed by the Zope developers, I can't imagine a non-Zope person being interested at all. As far as I can tell, the Zope Framework is a project management structure, not something outsiders would be interested in. -- Benji York Senior Software Engineer Zope Corporation ___ 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.app.generations/trunk/src/zope/app/generations/README.txt made blocks consistent
On Mon, Apr 6, 2009 at 11:47 AM, Baiju M mba...@zeomega.net wrote: On Mon, Apr 6, 2009 at 12:46 AM, Michael Howitz m...@gocept.com wrote: Am 05.04.2009 um 22:00 schrieb Baiju M: In reStructuredText, I think two colons :: is required to make it source text ? No, double colons mark literal blocks [1]. Doctest blocks are marked by at the beginning of the line. [2] [1] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#literal-blocks [2] http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#doctest-blocks Why we cannot use literal blocks for source code ? From the above documentations, I can see that it works for doctest. And we have used it in many places. Also in PyPI (long_description), it looks better. Please see http://mail.zope.org/pipermail/zope-dev/2008-August/033010.html (adding zope-dev and removing checkins) -- Benji York Senior Software Engineer Zope Corporation ___ 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.app.generations/trunk/src/zope/app/generations/README.txt made blocks consistent
On Mon, Apr 6, 2009 at 2:19 PM, Baiju M mba...@zeomega.net wrote: On Mon, Apr 6, 2009 at 11:56 AM, Benji York be...@zope.com wrote: [snip] Please see http://mail.zope.org/pipermail/zope-dev/2008-August/033010.html So we should not use either single colon (:) or indent doctest ? Single colons are fine, but they don't mean anything to reST (I don't use them much). Indenting doctests isn't required, but it is the prevailing style, so I'd like to keep doing it. -- Benji York Senior Software Engineer Zope Corporation ___ 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.annotation/trunk/setup.py Whitespace fixes
On Thu, Apr 2, 2009 at 9:37 AM, Zvezdan Petkovic zvez...@zope.com wrote: This would be more consistent, is sorted, and ensures easy addition/ removal of each line including the first, and the last line in the lists. install_requires=[ 'setuptools', 'zope.component', 'zope.interface', 'zope.location', 'zope.proxy', ], extras_require=dict( test=[ 'ZODB3', 'zope.testing', ], ), +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setting missing minimum version in setup.py
On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen faas...@startifact.com wrote: Stephan Richter wrote: On Sunday 15 March 2009, Wichert Akkerman wrote: If the package does not work with an older version of zope.publisher than imho that version restriction *has* to be in setup.py. And what if I backport the fix? We have done version specification like this in the Zope packages before and it almost brought development to complete halt, because versions would not match anymore. I'm not sure I agree you here, Stephan. A possible disagreement within the steering group, how interesting! :) I think more specific open requirements (as opposed to the most widely open requirement) can be very useful. Useful to the maintainers of the Zope Framework KGS, the Zope 3 KGS, the Grok KGS, the Zope 2 KGS, and to application specific lists of packages, and users who are developing or testing packages in some other way. I've used this pattern quite successfully when developing a bunch of related packages. I don't like version requirements in setup.py because they assume too much about how people are using the package. Lets say that someone adds two bug fixes to zope.foo (call them fix A and fix B) and then does a release. Fix A requires zope.bar = 1.5 and fix B doesn't. If I want to benefit from fix B in my app (and don't use the feature fix A repaired), then I shouldn't be forced to upgrade zope.bar. Another way to look at it: Just because a package's test suite won't pass without a particular version of a dependency doesn't mean that every user of the package needs that version of the dependency. If there were a way to ignore setup.py version requirements I'd be happy to have them and ignore them. Alternatively (my preference) the package would set versions in its buildout using the KGS against which it works (plus any exceptions). People could then refer to that to know what versions it actually works with and they can verify that it works by running the tests. -- Benji York Senior Software Engineer Zope Corporation ___ 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] Namespace declaration using pkgutil vs pkg_resources
On Wed, Mar 11, 2009 at 3:22 PM, Shane Hathaway sh...@hathawaymix.org wrote: Nit: In this case, two lines are better than one. import pkg_resources pkg_resources.declare_namespace(__name__) There's no need to use the lesser known __import__ function when an ordinary import statement will do. Indeed. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposal: refactoring of zope.app.security
On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/11 Martijn Faassen faas...@startifact.com: You should write up a short description of what zope.principalregistry does. In fact whenever we propose a new package we should describe its mission statement in just a couple of lines. That'll help us think about it better. I'll add a short README.txt to each package. The zope.principalregistry is an non-persistent implementation of IAuthentication that allows us to define principals via zcml (the principal directive and company) or with simple python calls. It's also quite useful for tests. bikeshed Maybe we can use the description or long_description field in the setup.py for the package mission statement /bikeshed -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 6:01 PM, Gary Poster gary.pos...@gmail.com wrote: If we do make changes for this purpose, I'd like to no longer use the __*__ pattern. +1 -- new or changed attributes should follow some other pattern -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] the future of ZCML slugs?
On Fri, Mar 6, 2009 at 9:52 AM, Martijn Faassen faas...@startifact.com wrote: Since nobody spoke up in favor of ZCML slugs, I'm going to record an official policy they can be removed. +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Baiju M wrote: On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev nad...@gmail.com wrote: 2009/3/2 Tres Seaver tsea...@palladion.com: -include package=zope.file/ I believe people still use the ZCML slug files like the above. They certainly aren't related to 'zpkg'. The intent of the slugs was to allow for something like 'sites-available' / 'sites-enabled' (the pattern in a stock Debian Apache2 install). I think it is particularly unfortunate to remove support for explicit, granular configuration at the same time as folks seem to be jumping to implicit (aka majyk) tools. Please revert this part of the change. I just reverted the change, however, I don't think that the slug files are useful anymore. I cannot see similar slugs in other packages either. Agreed. I don't understand Tres's or Benji's point either; thanks to buildout we've left such slugs long behind us I thought. Typically people would symlink these into an old old installation of Zope 3 (or copy them over). Explicit granular configuration isn't broken at all; if you want to explicitly include zope.file, you include its configure.zcml, not its zope.file-configure.zcml. Unless Tres comes back with some convincing explanation soon, please do get rid of this stuff. Those files exist to allow for a use case we may have abandoned, which is allowing packages to be installed in such a way that a tool could help users enable / disable their configurations, without mutating something like 'site.zcml'. The folks who might have that usecase are those who package zope3 components for deployment outside buildout (as .deb / .rpm, etc.) I don't know if there is such an audience; Benji also pointed out that he thought there were such folks. I don't doubt there are still at least a few, but I also don't think we are supporting that use case very well moving forward. We just need to make an explicit decision to drop support, and then we can remove the slug files. My initial reaction to Dan's removal was that the checkin message (remove zpkg stuff) had nothing to do with that particular change: 'zpkg' was entirely separate from slugs. Same here. -- Benji York Senior Software Engineer Zope Corporation ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py extra dependencies
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen faas...@startifact.com wrote: [snip proposal to stop using extras] Opinions? +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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.file/trunk/ Update package mailing list address. Remove zpkg stuff.
On Mon, Mar 2, 2009 at 11:38 AM, Dan Korostelev nad...@gmail.com wrote: Log message for revision 97423: Update package mailing list address. Remove zpkg stuff. Deleted: zope.file/trunk/src/zope/file/zope.file-configure.zcml === --- zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:09:01 UTC (rev 97422) +++ zope.file/trunk/src/zope/file/zope.file-configure.zcml 2009-03-02 16:38:27 UTC (rev 97423) @@ -1 +0,0 @@ -include package=zope.file/ I believe people still use the ZCML slug files like the above. -- Benji York Senior Software Engineer Zope Corporation ___ 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: z3c.mimetype/ Create infrastructure for z3c.mimetype
On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev nad...@gmail.com wrote:
2009/2/24 Baiju M mba...@zeomega.net:
Hi Dan,
On Tue, Feb 24, 2009 at 6:40 PM, Dan Korostelev nad...@gmail.com wrote:
Log message for revision 97207:
Create infrastructure for z3c.mimetype
Changed:
A z3c.mimetype/
I thought of sharing this with you, may be useful. I have got one tip from
Jim for creating a new project area:
http://mail.zope.org/pipermail/zope3-dev/2006-October/020701.html
Heh, nice trick with `z` :) Thank you.
A slight refinement:
svn mkdir path-to-repo/new-project{,trunk,tags,branches}
Using the `z` trick, that would be:
svn mkdir `z`/new-project{,trunk,tags,branches}
--
Benji York
Senior Software Engineer
Zope Corporation
___
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: z3c.pt/trunk/CHANGES.txt Reformatted changelog dates.
On Fri, Feb 20, 2009 at 2:41 AM, Michael Howitz m...@gocept.com wrote: Am 19.02.2009 um 18:48 schrieb Malthe Borch: Log message for revision 96790: Reformatted changelog dates. Changed: U z3c.pt/trunk/CHANGES.txt -=- Modified: z3c.pt/trunk/CHANGES.txt === --- z3c.pt/trunk/CHANGES.txt 2009-02-19 17:28:43 UTC (rev 96789) +++ z3c.pt/trunk/CHANGES.txt 2009-02-19 17:48:37 UTC (rev 96790) @@ -1,21 +1,21 @@ Changelog - -Version 1.0b9 - February 19, 2009 -~ +1.0b9 (2009/02/19) +~~ ISO dates (-MM-DD) are more clearly to read. When using slashes it is not always clear what is the month and what is the day. +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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 3.4.0 Released!
On Sat, Jan 31, 2009 at 2:33 AM, Stephan Richter srich...@cosmos.phy.tufts.edu wrote: - Zope 3.4 Versions: http://download.zope.org/zope3.4/3.4.0/versions.cfg I had been using http://download.zope.org/zope3.4/versions.cfg, but that has gone away. Was I using the wrong thing? Was the removal of the old file intentional? -- Benji York Senior Software Engineer Zope Corporation ___ 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] zope3docs
On Mon, Feb 2, 2009 at 11:49 AM, Christian Theune c...@gocept.com wrote: I've created a project in SVN labelled zope3docs and thought I'd let you know what I intend to start doing there. My short-term goal is to produce a document that I can pass to new developers with reasonable confidence that they know roughly how to move in our community. A hearty +1 from me. I have very little time to spend, but I'm sure I'll at least read what you produce in hopes of helping how I can. -- Benji York Senior Software Engineer Zope Corporation ___ 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 )
