Re: [Zope-dev] [TIP] zope.testrunner and nose count doctests differently
On Wed, Nov 9, 2011 at 2:53 AM, Chris Withers 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 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 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, 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 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 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 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 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 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 wrote: > I always found configuration overrides (e.g. ZCML's > 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: > > 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 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] ZODB replication and high-availability across data centers
On Thu, Oct 21, 2010 at 11:32 AM, Andreas Jung wrote: > we are currently investigating options for a large-scale solution > where the machines (ZEO clients and ZEO server) should be separated > across two data centers. Incoming traffic should be balanced between > both data centers. Automatic failover and online-replication are > desirable - "high-performance" is a must. Do you need to have each data center write to the database(s)? -- 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 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 wrote: > On Wed, Jul 14, 2010 at 19:22, Benji York 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 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 Thu, Jul 1, 2010 at 11:34 AM, Tres Seaver 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] Zope Tests: 42 OK, 3 Failed
On Tue, Jun 29, 2010 at 3:18 PM, Tres Seaver 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] version pinning on tags
On Thu, Apr 29, 2010 at 9:46 AM, Stephan Richter wrote: > On Thursday 29 April 2010, Baiju M wrote: >> > +1 to use a KGS. ZTK or BB depending on what the dependencies are. >> >> Since normally we don't pin versions in trunk, I guess we need to >> do the pinning in maintenance branches. Otherwise we can >> keep the version pinning in trunk, but comment the "versions" option. >> Then, just before going for release, uncomment it. >> This will become one more step in creating releases: >> http://docs.zope.org/zopetoolkit/process/releasing-software.html > > Why not leave it always pinned? This way the pinning gets transferred to the > branch/tag automatically. +1 Nailing versions on the trunk means that the trunk is always functional and the result of building the trunk doesn't depend on what versions were available when you built it (as Adam mentioned). -- 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 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] RFC: Proposed new style for documenting and testing ZTK packages
On Mon, Apr 19, 2010 at 7:21 AM, Charlie Clark 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] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
On Fri, Apr 9, 2010 at 10:57 AM, Fred Drake 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 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:34 AM, Brian Sutherland 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 >> 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] Uses of the ZTK and how it relates to management
On Thu, Mar 4, 2010 at 11:09 AM, Brian Sutherland 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] Adding W3C validating to zope.testbrowser
On Tue, Feb 23, 2010 at 9:57 AM, Marius Gedminas 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] Adding W3C validating to zope.testbrowser
On Sat, Feb 20, 2010 at 7:53 AM, Ross Patterson wrote: > I started a branch for doing W3C HTML validation on responses to > zope.testbrowser requests: > > svn://svn.zope.org/repos/main/zope.testbrowser/branches/rossp-validator > > The idea is to be able to flip a switch and run all my functional > zope.testbrowser tests and see validation failures as test failures. I'm not keen on this idea. Validation checking isn't hard to do with testbrowser as-is, and doing it on every page load is overkill. Add to that the global nature of the required switch and this really doesn't seem like the right approach. I suggest you create a package that subclasses testbrowser to provide the behavior you want. Perhaps if it is widely adopted and the approach proves itself, it can be rolled in. > Does this belong in zope.testbrowser or in the underlying mechanize > package? It appears to me to belong higher in the stack, not lower. I do like the local validator approach. How will you manage that dependency? -- 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 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] small manuel bugfix
On Fri, Dec 25, 2009 at 9:37 PM, Chris McDonough 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] 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] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:43 PM, Chris McDonough 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] patterns for using sphinx with the Zope Toolkit?
On Sun, Jan 3, 2010 at 6:53 AM, Martijn Faassen 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 4:48 PM, Lennart Regebro wrote:
> On Sun, Jan 3, 2010 at 22:08, Benji York 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] zope.testing 3.8.6 emits deprecation warnings from itself?
On Wed, Dec 30, 2009 at 7:45 AM, Marius Gedminas wrote: > On Wed, Dec 30, 2009 at 08:58:52AM +0100, Lennart Regebro wrote: >> On Tue, Dec 29, 2009 at 23:47, Marius Gedminas 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 Sat, Jan 2, 2010 at 8:44 PM, Chris McDonough 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] patterns for using sphinx with the Zope Toolkit?
On Sat, Jan 2, 2010 at 2:21 PM, Martijn Faassen wrote: > It'd also be interesting to explore using Manuel - how would one add > manuel-based testing to a Sphinx documentation tree? I'd like to give > the priority to testing documentation samples as opposed to > doctest-driven testing. The Manuel docs use both Sphinx and Manuel, so should be good examples. I don't use a Sphinx recipe at the moment though. I just used zc.recipe.egg:script. See [sphinx-docs-html] and [build-docs] in the Manuel buildout.ini for details (http://svn.zope.org/*checkout*/manuel/trunk/buildout.cfg). > I also want to be careful: sometimes the doctest > setup fluff tends to distract from clear documentation, and sometimes > the effort in composing doctests will slow down writing documentation. You can hide setup code using Manuel: http://packages.python.org/manuel/#invisible-code-blocks. > I'd therefore want manuel-tested sample code to be incremental. I want > to be able to start out with purely untested sample code and then > gradually convert *some* samples over to Manuel. How could we support > that pattern? Manuel lets you specify which pieces of code should be run and which should be ignored (http://packages.python.org/manuel/#ignore). -- 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 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 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 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 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 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] Get rid of doctest.py in zope.testing? (Was: Bootstrapping ZCA for Python 3.)
On Mon, Dec 7, 2009 at 4:08 PM, Lennart Regebro wrote: > For example: Exceptions in Python 3 print out the whole module path of > the exception, while in Python 2 it's only the classname: Immediate > doctest failure. This is fixable in your doctests by trapping the > exception instead, which is what I've done. You can also use a normalizer. They make dealing with these sorts of inter-Python formatting differences pretty easy. > Efforts to remove doctests failed on the INTERPRET_FOOTNOTES options, > which the standard Python doctests doesn't support. A quick search > turns out that ZODB, zc.catalog, zc.relation, zc.async, zc.sharing, > zc.freeze and lovely.remotetask uses it, maybe more. Those tests could probably use Manuel's footnote support instead, but that would add one more dependency (Manuel) that would have to be ported to Python 3 -- and I don't have any expectation that I'll be doing that in the near future. > I really think it's a bad idea to have a special version of > doctest.py. I think we should get rid of it. I'd like for them to be unified too, but even ignoring INTERPRET_FOOTNOTES, the two have drifted apart quite a bit. The last time I looked at it I stopped after spending several frustrating hours comparing diffs and trying to get one's tests to run on the other. Maybe you'll have more success than I did. -- 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 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] ZCA proposal
On Thu, Dec 3, 2009 at 5:27 AM, Shane Hathaway 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 IFoo for single adapters and IFoo for multiapdapters. I suppose we could do: IFoo<> and IFoo<> 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] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman 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=detail&aid=2793544&group_id=66150&atid=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=detail&aid=2906878&group_id=66150&atid=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] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 5:06 PM, Marius Gedminas 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] zope.testing.testrunner.debug.post_mortem and try/finally
On Wed, Dec 2, 2009 at 1:22 PM, Ross Patterson 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] improving the utility and adapter lookup APIs
On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida wrote: > On Thu, Nov 26, 2009 at 14:34, Benji York 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 Thu, Nov 26, 2009 at 6:52 AM, Hermann Himmelbauer 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] Releasing zope.browserresource
On Thu, Nov 26, 2009 at 4:57 AM, Wichert Akkerman 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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes 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] improving the utility and adapter lookup APIs
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen 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] Releasing zope.browserresource
On Wed, Nov 25, 2009 at 1:16 AM, Thomas Lotze 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] Zope3 server with SIGSEGV - what to do?
On Wed, Nov 25, 2009 at 1:42 AM, Hermann Himmelbauer 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] Zope3 server with SIGSEGV - what to do?
On Tue, Nov 24, 2009 at 4:04 PM, Hermann Himmelbauer 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] make zope.component.registry.Components inherit from dict?
On Tue, Nov 24, 2009 at 6:22 AM, Chris McDonough 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] Testrunner option for running tests in random order?!?
On Fri, Oct 9, 2009 at 8:51 AM, Jonathan Ballet 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 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 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 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] official release policy ZTK is still not changed
On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton wrote: > On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen > 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:41 AM, Martijn Faassen wrote: > Benji York wrote: >> On Fri, Sep 11, 2009 at 8:53 AM, Martijn Faassen >> 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Fri, Sep 11, 2009 at 10:30 AM, Gary Poster 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 8:53 AM, Martijn Faassen 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 9:07 AM, Marius Gedminas 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 2:20 AM, Wichert Akkerman 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 Thu, Sep 10, 2009 at 5:20 PM, Wichert Akkerman 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] [Checkins] SVN: zope.app.security/trunk/ keep trunk version at 0. Update changes
On Thu, Sep 10, 2009 at 4:12 PM, Hanno Schlichting wrote: > On Thu, Sep 10, 2009 at 9:46 PM, Alex Chapman 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] writing and checking files with Manuel [PS]
On Tue, Sep 8, 2009 at 1:08 PM, Chris Withers 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] Subversion externals versus mirroring
On Wed, Sep 9, 2009 at 12:40 PM, Christian Theune 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 3:05 PM, Jim Fulton wrote: > On Fri, Aug 14, 2009 at 2:58 PM, Benji York wrote: >> On Fri, Aug 14, 2009 at 2:51 PM, Jim Fulton 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. 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] 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 Fulton 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 2:13 PM, Jim Fulton wrote: > On Fri, Aug 14, 2009 at 1:58 PM, Benji York 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 1:20 PM, Jim Fulton wrote: > On Fri, Aug 14, 2009 at 1:03 PM, Chris Withers 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] [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 Schnerring 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 Gedminas 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 )
Re: [Zope-dev] Manuel Beta
On Wed, Jun 24, 2009 at 6:07 PM, Chris Withers wrote:
> Benji York wrote:
>>
>> --- begin quote ---
>>
>> Contents of myfile.zcml::
>>
>> http://namespaces.zope.org/zope";>
>> blah blah blah
>>
>>
>> .. -> 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::
http://namespaces.zope.org/zope";>
blah blah blah
.. -> 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::
http://namespaces.zope.org/zope";>
blah blah blah
.. -> 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::
http://namespaces.zope.org/zope";>
blah blah blah
.. 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] Manuel Beta
On Wed, Jun 24, 2009 at 12:59 PM, Sebastien Douche 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 5:06 PM, Chris Withers 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('''
>>>> http://namespaces.zope.org/zope";>
>>>> blah blah blah
>>>>
>>>> '''.strip())
>>>> f.close()
>>>> zope.configuration.xmlconfig.file(join('mytempdir','myfile.zxml'))
>
> I could have:
>
> .. file:: myfile.zcml
>
> http://namespaces.zope.org/zope";>
> blah blah blah
>
There's no super-nice way to do exactly that, but here's a pretty
reasonable version:
--- begin quote ---
Contents of myfile.zcml::
http://namespaces.zope.org/zope";>
blah blah blah
.. -> 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::
http://namespaces.zope.org/zope";>
blah blah blah
.. -> 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 )
[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] tabs in the source
On Mon, Jun 22, 2009 at 1:16 PM, Adam GROSZER 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 Zagrodnick 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 Ineichen 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 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 : > 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:55 AM, Wichert Akkerman wrote: > Previously Benji York wrote: >> On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman 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] Release management proposal
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman 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] z3c.javascript license question
On Fri, Apr 17, 2009 at 3:48 PM, Tres Seaver 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 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 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 2:19 PM, Baiju M wrote: > On Mon, Apr 6, 2009 at 11:56 AM, Benji York 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.app.generations/trunk/src/zope/app/generations/README.txt made blocks consistent
On Mon, Apr 6, 2009 at 11:47 AM, Baiju M wrote: > On Mon, Apr 6, 2009 at 12:46 AM, Michael Howitz 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.annotation/trunk/setup.py Whitespace fixes
On Thu, Apr 2, 2009 at 9:37 AM, Zvezdan Petkovic 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 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] Proposal: refactoring of zope.app.security
On Wed, Mar 11, 2009 at 1:52 PM, Dan Korostelev wrote: > 2009/3/11 Martijn Faassen : > >> 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. Maybe we can use the "description" or "long_description" field in the setup.py for the "package mission statement" -- 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 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] Python3 and attribute annotations.
On Mon, Mar 9, 2009 at 6:01 PM, Gary Poster 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 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] setup.py "extra" dependencies
On Thu, Mar 5, 2009 at 1:43 PM, Martijn Faassen 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 Wed, Mar 4, 2009 at 6:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martijn Faassen wrote:
>> Baiju M wrote:
>>> On Tue, Mar 3, 2009 at 2:35 PM, Dan Korostelev wrote:
>>>> 2009/3/2 Tres Seaver :
>>>>>>> -
>>>>>> 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 )
