Re: [Zope3-dev] zc.testbrowser.real depends on python 2.5
Paul Winkler wrote: Looks like zc.testbrowser 1.0a1 has a small dependency on Python 2.5. NameError: global name 'any' is not defined Actually, it's a function that is defined in zope.testbrowser and was lost in translation to zc.testbrowser. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-dev] AW: [Zope3-dev] I'd lobe to merge the zope3-dev and zope-dev lists
Andreas Jung wrote: we want to get rid of the term Zope 3 in the future That's news to me. Perhaps for some definition of we. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Known-good-sets problem
Stephan Richter wrote: 2. How many packages should be controlled in this index? I think we should definitely add packages from z3c and the zc namespace. What is the motivation to include non-controlled packages? I suppose it is to let people use those packages with (in this case) Zope 3.4. What if someone wants Zope 3.4 and Twisted version X and Plone version Y (just making those up). Perhaps we need a way to refer to several KGS when constructing an application. Or is one KGS supposed to define a universe of packages known to work together. If so, I would think there would be no place for non-controlled packages. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release process closure
Jim Fulton wrote: I'd really like to get to closure on the current approved release process. +1 There are other improvements that might be made, but let's not let the perfect be the enemy of the good. This isn't perfect, so I get to suggest it. wink I propose that we codify the practice of release tags having their x.y.z version number as their name, and in the setup.py. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release process closure
Jim Fulton wrote: For example, a packaging of MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is exciting enough: 1.3.1-1.1 I assume setuptools interprets version numbers like this in a reasonable way. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
Tres Seaver wrote: I would prefer that we quit releasing non-source distributions at all; the exceptions would be Windows eggs for packages containing extensions. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.testbrowser alpha 1 released
Christian Theune wrote: Annotation to the bikeshed: If we want to avoid having to rewrite tests for real or unreal test browsers, I would avoid having to call two separate browser factories but let something like the test layer handle which one is used, that way you could easily switch. Yep, I'm glad you mentioned it. I plan to rework the doctests to be more documenty in the near future and will mention this as a best practice. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.testbrowser alpha 1 released
zc.testbrowser 1.0a1 I am very pleased to announce the first alpha release of zc.testbrowser: http://pypi.python.org/pypi/zc.testbrowser zc.testbrowser is a refactoring of zope.testbrowser to remove the Zope-specific bits plus the addition of the zc.testbrowser.real module. Testbrowser Real zc.testbrowser.real lets you use the testbrowser API to drive a real web browser; at the moment Firefox (but we may add support for others in the future). This lets you do testing of JavaScript heavy web applications with testbrowser (and doctests, of course). I envision people often beginning tests using the regular testbrowser, realizing the test/documentation they want to write needs JS, and then switching their test to use real and not having to change the already written parts of the doctest. Screen Shots One other feature of zc.testbrowser.real is the ability to save the current web page to a PNG file. This should be very useful for creating user manuals with embedded screen shots. Thanks -- Many, many thanks to my partners in crime at the Foliage Sprint: Stephan Richter, Rocky Burt, and Justas Sadzevičius. Bikeshedding Request Even though I coined it, I don't really like the name real. I'd like suggestions that are short, pithy, and descriptive if anyone has any. Along the same lines, any suggestions for a new name for zc.testbrowser.browser (the classic testbrowser) would be appreciated as well. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why do we restrict our egg testing?
Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. Why do we not use a Zope3 meta egg which contains all our zope packages as a test base. This whould allow us to test the same we have in the zope3 trunk and let us run *buildout/test -s zope* from within each egg. Perhaps because there isn't a Zope 3 meta egg. btw, what is the builbot doing right now? Does the builbot still runs test on the trunk? Or does the buildbot test the eggs? It doesn't do much of value at all right now. The transition to individual projects per package has left it behind. There are good ideas to make the buildbot work with the new setup, now we need someone to implement them. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Why do we restrict our egg testing?
Roger Ineichen wrote: Hi Benji Betreff: Re: [Zope3-dev] Why do we restrict our egg testing? Roger Ineichen wrote: Can anybody tell me why we restrict our test setup in zope eggs and only use a subset of package for our test setup? I don't know what you're asking, so I can't tell you why it is wink. I mean, we don't use all zope packages in our test dependency if we develop eggs. What was the reason to use a subset of of zope packages for egg testing? e.g. extras_require = dict( test = [ 'zope.testbrowser', 'zope.app.securitypolicy', 'some more zope.* packages but why not all zope.*' ], ), Two things. extras are bad, and shouldn't be used, put test dependencies in the real dependencies. Second, why would you include all of the zope.* eggs if that particular package doesn't depend on them? Is there a benefit to not depend on all zope.* packages in each egg test setup if we do a transition to indvidual packages? I understand the benefit to have smaller dependencies in eggs, but I still think a egg should run all tests we have in the zope namespace. Like we did in our old trunk setup. This whould allow us to run all zope.* tests during egg development. It sounds like it would build the equivalent of the old-style Zope 3 trunk for each and every zope.* buildout. That sounds awful. Perhaps I'm misunderstanding your proposal. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: faulty releases and pypi access [update]
Philipp von Weitershausen wrote: Stephan Richter wrote: Because I disagree with that, since you cannot know the next version. You can always know the minimum version. If you just released 3.4.2, I think it's sensible to point the next release to 3.4.3. If you later decide that you really need a feature release, you can always bump to 3.5.0a1 (which would be the first release in the 3.5.x series). Why not leave the version totally out of the setup.py in the trunk? After branching for a release we can set the version (e.g., 1.2), make a release, and tag the branch. We could either leave the version on the branch at the last release or continue the trend of mad bumping and have it at the next release (which since this is a branch, we can actually predict). I prefer the last version, but next would work too. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.testbrowser packaging
Philipp von Weitershausen wrote: So here's what I suggest: Factor out a) to a new package 'zc.testbrowser' (or whatever) and make 'zope.testbrowser', the remaining b), depend on zc.testbrowser, zope.app.testing and all that other stuff properly. This is what I've decided to do. This approach also has the nice side effect that I don't have to constantly say 'zope' is just a package name space, you can use testbrowser outside of zope. Unfortunately I don't think we can ever overcome the powerful Zope brand for non Zope-specific projects/packages. People think anything with zope in the name has to do with the publisher. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testbrowser packaging
I have a small issue with zope.testbrowser packaging I'd like to get some input on. If I were to have started the project today, it would likely have been zc.testbrowser, which would have no Zope 3 dependencies (or functionality) and zc.testbrowser.zope, which would have, and depended on zc.testbrowser. Well, that didn't happen, but there are parallels to the current situation that might be informative. There is a configuration bug in testbrowser that means that unless you include the test extra, you won't get the Zope 3 dependencies. I suspect most people either include that extra, or accidentally include the dependencies through other packages. I have two ideas for fixing this: 1) introduce a zope extra that everyone will have to use (basically just rename test to zope; 2) take a lesson from the fictional zc.testbrowser and introduce another package (zope.testbrowser.zope) that contains the Zope 3 bits and depends on zope.testbrowser. I think I prefer the second, despite it's strange appearance. Thoughts? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zope.testbrowser 3.4.1
zope.testrowser 3.4.1 generates non-backward-compatible tracebacks for HTTP errors. 3.4.2 will be released soon(-ish) to fix this, in the mean time please continue to use 3.4.0. Thanks. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: broken zope.lifecycleevent 3.4.0 on cheeseshop?
Baiju M wrote: BTW, do we need to upload eggs to http://download.zope.org/distribution/ any more ? If we feel that depending on PyPI to install zope packages is OK, then we can decommission /distribution/. For the commercial projects I'm involved in we make sure we have private copies of everything we depend on, so I don't have a desire to keep /distribution/ around. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: AW: [Zope3-dev] Re: [StabilizeEggPackages] (edit) Is that all thathas to be done in setup.py?
Roger Ineichen wrote: Benji, Is there a IP range which get blocked for accessing http://svn.zope.org (e.g. Google bots traffic)? No idea if there is an IP range blocked, but the svn.zope.org robots.txt disallows all robots, so the effect is the same. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Fred Drake wrote: On 8/24/07, Stephan Richter [EMAIL PROTECTED] wrote: But if you prefer consistency, then we really should be staying with the Zope 3 style guide, This, of course, all depends on the answer to the question: Consistency with what? Zope 3 history? The larger Python community? (Don't think the world agrees on PEP 8...) Because my desire is to make individual Zope packages more widely adopted by the larger Python community and bring more people to Zope 3, I prefer PEP 8. As has been said of Python, more Python code will be written in the future than has been in the past, I hope the same is true of Zope. Hopefully, there are also more Zope users to come than we have ever had. Consistency is good, but we have to be consistent with the largest body of code/group of people as possible. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] setting up application dependencies
Martijn Faassen wrote: Benji York wrote: Darryl Cousins wrote: On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). Specifying versions should be done by the application (buildout for example), not setup.py. If versions are put in setup.py they limit what others can do with the version requirements (e.g., relaxing them). The problem with this approach is that everybody setting up an application will need to know a lot about version numbers. I like reuse. I don't want to expose, say, all users of Grok, to a lot of version numbers they need to set. I thin that's actually a third case. So far we have projects, applications, and now frameworks (for lack of a better word). Grok strikes me as a framework because you want to specify a known-good set of versions, but not in an all-in-one application distribution. So, in case of Grok what we don't want is that everybody needs to hardcode all kinds of version numbers into their own buildout.cfg. *the same* version numbers, typically. I'm not sure what the right approach is there, a simple versions.cfg that contains the suggested versions might be sufficient. We'd want this list of version numbers to be maintained by the Grok developers instead. We could of course make our 'grokproject' tool generate the hardcoded dependencies for users, but that seems rather odd too. This means that if someone wants to update their grok-based application to a newer version of Grok (which requires a newer version of say, zope.security), they will still need to go in and edit their buildout.cfg. That sounds difficult to communicate and difficult to maintain. As above, perhaps grok_versions.cfg could be one of (or the only) thing your users download. That's an interesting thought, the Grok project can produce lots of code and distributions and when it's time for a release, you release the grok-1.2-versions.cfg that people can update their local grok-versions.cfg with. I wonder if that model would work for future releases of Zope 3. In case of Grok, I think we do have such a central place: grok's setup.py. If we hardcode version numbers there, there's no more need for people to start putting it in their buildout.cfg. It also means that if people require a newer version of a library that Grok also depends on, they will have to talk to the Grok developers and ask for an update. I think that may have good side effects: the grok developers can then first test with this updated library and after a new version of Grok is released, everybody will have the benefit of the newest version of the library. That level of rigidity doesn't sound like much fun to me. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Guide for maintaining software in the Zope repository
Andreas Jung wrote: Can someone please point out the major differences concerning Python code between PEP 8 and the Zope 3 style guide? The primary differences are in method, attribute, function, and variable names. PEP 8 specifies lower_case_with_underscores. Zope 3, more often than not (as noted by others, inconsistencies exists), follows these conventions: http://wiki.zope.org/zope3/ZopePythonNamingConventions specifies CamelCase for Public global variables (not exactly sure what all that encompasses) and lower_case_with_underscores for local variables. The same page prescribes mixedCase for module-level (non-factory) functions. http://wiki.zope.org/zope3/ClassesAttributesMethods specifies mixedCase for attributes and methods. BTW: http://wiki.zope.org/zope3/CodingStyle (like most of the Wiki) is a mess. I may cut out some outdated chunks (including 5 year old comments) if no one objects. Are there any guidelines for the wiki? I looked but couldn't find any. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Dependency cleanup: zope.traversing
Christian Theune wrote: I've moved the `etc` namespace class to zope.app.publication in my sandbox. During testing I noticed that zope.app.testing has a dependency on zope.traversing for traversing ++etc++sitemanager when creating a site manager. I can change this to use a different lookup mechanism. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Christian Theune wrote: From my latest experience and research of when to use exceptions and when to use return values I'd say let's not use an exception. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add function for schema validation in zope.schema
Wichert Akkerman wrote: That would be confusing though: I would expect the result of a method that checks validaty to return something that evaluates to True if everything is valid. Code like this just messes up my brain: if not zope.schema.validate(obj, IMySchema): print Everything validates correctly! to me that is very non-intuitive and looks like the if condition is incorrect. Agreed. I prefer to name boolean methods with an is prefix. Then we would have if zope.schema.isValid(obj, IMySchema): print 'valid' and if not zope.schema.isValid(...): print 'invalid' That doesn't give any information about what is invalid though, I'd use a separate method for that. Perhaps something like getValidationErrors. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: AW: Re: AW: relying on win32api in windows supportofzc.zope3recipes
Martijn Faassen wrote: It would be nice if one could install Zope 3-based *applications* using a Windows installer. But to ask developers to install all the *library* dependencies separately using click-through wizards is rather strange. As a recovering Windows developer, I agree. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Heads up: major change in zc.buildout policy for selecting distributions
Jim Fulton wrote: I'm about to make a new release of zc.buildout that uses a different policy for selecting distributions. In particular, by default, zc.buildout will now prefer final distributions over non-final ones. Yay! -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Removed zope.security 3.4b4
Darryl Cousins wrote: On Fri, 2007-08-17 at 19:24 +0200, Martijn Faassen wrote: I think my next step is to fix some dependencies for Grok to hard version numbers... I think that this is a good thing. I recently gave myself quite a bit grief with a careless bin/buildout which broke my application. To avoid that I need to be more specific in setup.py. (I haven't attempted it yet though). Specifying versions should be done by the application (buildout for example), not setup.py. If versions are put in setup.py they limit what others can do with the version requirements (e.g., relaxing them). I haven't noticed that any of the maintained packages on svn.zope.org have specified egg version numbers in the dependencies. (install_requires). Should perhaps example be set by beginning to do so? I prefer versions be specified (by buildout) for my packages, it helps make development a lot more deterministic. One downside is that bugs (including incompatibilities) in packages are found later because new version uptake is much slower with nailed versions. One upside, as you've discovered, is that you don't have version changes forced upon you. A nice mix of the two approaches will be possible when buildout supports the only use release eggs option. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Removed zope.security 3.4b4
Martijn Faassen wrote: Given the momentary confusion surrounding the release of a broken package. By broken package in this case I mean something which seriously breaks many many Zope 3 installations in an obvious way. I think it might be wise to start working out some procedure surrounding such a situation. The procedure that appeals most to me is for buildout to be modified to prefer release eggs by default (the work for this has been done, and should be released soon). I also recommend projects nail their version requirements so that no matter what someone releases, they will be unaffected. This is how we run the projects I'm involved in, and it helps that we can decide, on occasion, to pay off our version debt all at once, and not have someone else create emergency work for us. * if a package is broken, the preferred route is to upload a new, fixed package with a later version number as soon as possible. (incidentally, it appears wise to verify manually that the new egg is indeed there by checking the download server.) +1 I'd therefore suggest that *if* we can't release a fixed egg for logistical reasons within a brief time-period, we proceed to remove the broken egg from the server and post a message to the mailing list saying it's broken. If buildout prefers release eggs, then only bad release eggs will cause the above problem. Coupled with nailed versions, there should be no reason for emergency communication or egg deletion. Having said that, I don't abhor the idea of an occasional purge of a bad, non-release egg. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] copied doctest in z3.zope3recipes for Windows support
Martijn Faassen wrote: These are all the changes in the test code I can detect. It therefore seems quite feasible to merge them into a single test again, if at least we can work out the buildout output differences. +1 It may be possible through the use of a normalizer and different setup code for the different platforms to unify the two tests. I personally would prefer to not see conditionals in the doctest itself. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Removed zope.security 3.4b4
Dieter Maurer wrote: Precisely fixing the dependancies is a good thing for final applications. +1 It is bad for components or in situations where the given application is composed from many mini-applications. I don't agree, but as long as I'm not working on your components, I don't mind. wink -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with zope.testbrowser
Adam Groszer wrote: Hello Fred, I'll say silence is consent. I'll need some time to merge. Might be I should write a test before. I'll try to take a look at the branch in the next couple of days and give you some feedback. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: help with doctests
Philipp von Weitershausen wrote: Sometimes, using ellipses are fine, but generally they obfuscate the doctest when you're reading it. I suggesting using the regex-normalizer [1]. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Problems with zope3 on windows
João Paulo Fernandes Farias wrote: Steps to reproduce: Thanks. I'm sure this information will help whomever works on this issue. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 needs a new documentation strategy
Luciano Ramalho wrote: One of the first questions anyone needs answered when studying a new framework is Where is the canonical reference for the API?. Whatever is done, http://wiki.zope.org/zope3 is probably the right place for it. Wasn't someone going to get zope3.org pointed to that page? Try googling for zope 3 api documentation... [1] Try googling for zope 3 documentation. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope 3 needs a new documentation strategy
Luciano Ramalho wrote: On 7/18/07, Benji York [EMAIL PROTECTED] wrote: Try googling for zope 3 api documentation... [1] Try googling for zope 3 documentation. I did also, the result is not better. I was overly succinct. I meant to indicate that the first search result for that phrase was http://wiki.zope.org/zope3/Documentation. I can't think of a more appropriate result. wink If you're instead wishing for the _content_ of that page to be better, then the search isn't the issue, but the page itself. I think everyone welcomes improvements there. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Problems with zope3 on windows
João Paulo Fernandes Farias wrote: I'm not sure if this is enough info to get stuff fixed, just wanted to tell about my experiences so far. Reproduction steps would be helpful, as well as full tracebacks of the various exceptions. I'm a bit surprised nobody noticed those issues so far, is windows so unpopular in zope3 / grok developers? lol In a word: yes. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Benji York wrote: It'd be nice to have a -C option that disables -c for when your test runner has -c included in the default options (as I intend to do with mine). I've added such an option. The -C switch makes sense, but I'm not entirely happy with the --no-color version of the name, any suggestions? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Benji York wrote: Marius Gedminas wrote: There's a little complication: when you have test layers that don't support tearDown, some of the tests are run in a subprocess, where stdout isn't a terminal (it's a pipe), but all the output will be copied verbatim to the stdout of the parent process (which may or may not be a terminal). The test runner could look at the top level stdout and pass the information to subprocesses. I've implemented this in revision 78022. The option name is --auto-color. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Doctests (was: Windows eggs)
Stephan Richter wrote: Okay, I am done preaching. ;-) Preach on, brother! -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Stephan Richter wrote: On Saturday 14 July 2007 15:30, Benji York wrote: Yep, assertions about HTML (or XML) are difficult to do with plain text. One option is to feed browser.contents to your favorite HTML (XML) parser. Right, z3c.etestbrowser does this already. I wish they would have done this with a different object altogether, but they extended the TestBrowser class. But then I do not have enough objectstion to write a new package. Perhaps someone can explain the utility of z3c.etestbrowser. As far as I can see, it just adds an etree attribute to browser instances. That doesn't seem to have much advantage over just calling etree on browser.contents. I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. The programmatic approach like above is one option. Another would be to use a special checker that took into account HTML/XML structure. For example, it could interpret ellipses differently such that foo ...Text here/foo would match foo a=bText here/foo but not foobar/Text here/foo -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Stephan Richter wrote:
I would not like that. I really, really like to use XPath to select an element
in the HTML structure. The method above would still require me to write
I think I miscommunicated. Let me combine your example and mine to
demonstrate what I was talking about. Say you have an HTML document and
you want to make assertions about a portion of it. You could use XPath
to extract part of the document and then use the smart ellipses to make
assertions about it. Like so:
browser.open(...)
Introspector(browser.contents).xpath('//foo')
foo ...Text here/foo
In the above example, the tester wants to extract the foo element, and
assert that its contents are Text here and that there are no child
elements. They don't want to make any assertions about it's attributes
so they put the ellipses there. Is that example clearer?
Of course, I really would prefer this:
print Introspector(browser).xpath1('//foo')
foo a=bText here/foo
This is so that the browser features and content inspection are separated.
Yep, I much prefer having this functionality in a separate object as
well; it's not really testbrowser specific.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Marius Gedminas wrote: On Sun, Jul 15, 2007 at 10:44:35AM -0400, Benji York wrote: I'm doing some work with doctest right now, and am considering how to make assertions about HTML/XML better. Fixing https://bugs.launchpad.net/zope3/+bug/126169 would make my life easier. I wonder if that behavior is present in the mainline doctest (the one included in the Python standard library). If so, reporting the issue to the Python team would be appropriate. My desire is that zope.testing will stop including a forked doctest. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Marius Gedminas wrote: On Sat, Jul 14, 2007 at 03:30:22PM -0400, Benji York wrote: Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. Merged. Yay! I'm already using it. :) I have a feature suggestion: it would be nice to have a switch to say colorize output, unless stdout isn't a terminal, so piping the output to a pager (or file) doesn't result in polluted output. There's a little complication: when you have test layers that don't support tearDown, some of the tests are run in a subprocess, where stdout isn't a terminal (it's a pipe), but all the output will be copied verbatim to the stdout of the parent process (which may or may not be a terminal). The test runner could look at the top level stdout and pass the information to subprocesses. It's not that hard to remove the -c flag when you're adding |less to the command line. Or you could use |less -R and have colourful and scrollable output. It'd be nice to have a -C option that disables -c for when your test runner has -c included in the default options (as I intend to do with mine). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Windows eggs
Marius Gedminas wrote: - Functional tests: these are .txt files that use zope.testbrowser and are the hardest to debug. There ought to be a better way to make assertions about HTML output than using ELLIPSIS and then pulling your hair out looking at huge and incomprehensible diffs. Yep, assertions about HTML (or XML) are difficult to do with plain text. One option is to feed browser.contents to your favorite HTML (XML) parser. Digression: syntax highlighting the diffs helps immensely. Check out http://svn.zope.org/zope.testing/branches/colorized-output/ I'm very much looking forward to that branch being merged to the trunk. I have a feature suggestion: it would be nice to have a switch to say colorize output, unless stdout isn't a terminal, so piping the output to a pager (or file) doesn't result in polluted output. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] How to debug zope3 if it completely hangs?
Fabio Tranchitella wrote: I'd like to know if zserver is a good choice for high loads or if it deprecated and I should stay with twisted. We run some pretty high load apps, and we're happy with zserver. Was zserver disabled only for security reasons? I don't believe it had anything to do with security. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.html/trunk/ZopePublicLicense.txt Add the ZPL text.
[moving this to zope3-dev] Brian Sutherland wrote: On Wed, Jul 11, 2007 at 07:31:13AM -0400, Benji York wrote: Brian Sutherland wrote: Log message for revision 77690: Add the ZPL text. Why? ## # # Copyright (c) 2004 Zope Corporation and Contributors. All Rights Reserved. # # This software is subject to the provisions of the Zope Public License, # Version 2.1 (ZPL). A copy of the ZPL should accompany this distribution. # THIS SOFTWARE IS PROVIDED AS IS AND ANY AND ALL EXPRESS OR IMPLIED # WARRANTIES ARE DISCLAIMED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED # WARRANTIES OF TITLE, MERCHANTABILITY, AGAINST INFRINGEMENT, AND FITNESS # FOR A PARTICULAR PURPOSE. # ## The important part is: A copy of the ZPL should accompany this distribution. I couldn't care less, but Ubuntu and Debian get very antsy if you ignore this point. Hmm, I'd hate for the license file to pollute the root directory of every, single project. Perhaps we can decide to put it in the src directory instead. Comments? We want schooltool to be distributed in Ubuntu, and schooltool depends zope.html. But actually, now, I see that there is no copyright headers in any file in zope.html. So I guess I have to either revert my commit, or add the headers. ZPL headers would be appreciated, thanks. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: [Checkins] SVN: zope.html/trunk/ZopePublicLicense.txt Add the ZPL text.
Fred Drake wrote: It seems that if the ZPL is required to be in distributions, it needs to be added to the result of setup.py sdist and the various bdist_* commands (including bdist_egg). +lots -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] problem with zope.testbrowser
Adam Groszer wrote: The problem is deep in mechanize. Updating mechanize+Clientform to the current versions (locally) helped. Some patching in testbrowser is necessary. Cool! Glad you're looking into this. Any advices for/against doing that on the trunk? I would prefer a branch, that way we can collaborate on it before merging it to the trunk. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.app.session/zope.minmax
Tres Seaver wrote: [1] This means *never* doing 'svn mv' or 'svn remove' on such a tag, once announced. No exceptions, period, even for brown bags. I can see that rule applying to eggs, but I'm not sure why we need to do it for tags. I don't really object, but would like to understand the motivation. Deleting tags of bad or ancient releases doesn't seem particularly onerous. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Don't need $Id$ string any more
Jim Fulton wrote: I propose we stop bothering to include $Id$ strings. (Note that I'm *not* suggesting we go out of our way to remove them.) +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Trunk open for feature development towards Zope 3.5
Christian Theune wrote: I've made the release branch for Zope 3.4, you can feel free to start introducing changes for Zope 3.5 into the trunk of the tree. Now would seem to be the time to discuss the fate of the big tree. It is entirely possible to build Zope 3 from eggs only, do we want to keep the trunk around? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Trunk open for feature development towards Zope 3.5
Stephan Richter wrote: Having said that, I think a Zope 3 meta egg would be a good start towards documenting how to build a Zope 3 application using eggs. Also, packages like z3c.formdemo give further help. I'll look into creating such a thing. Another final issue I see here are the problems we are having with the cheeseshop. I don't think it is ready for the Zope crowd yet. While I think that download.zope.org/distribution is used to get the packages, I have found that buildout comes to a halt when the cheeseshop is not working. It's possible to use zc.buildout (and setuptools as well, if I'm not mistaken) without accessing the cheeseshop. We set up some of our product buildouts that way. We could do something similar for the zope.org buildouts. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Trunk open for feature development towards Zope 3.5
Philipp von Weitershausen wrote: I personally prefer not working with the tree anymore. If people want to keep it around, that's fine, but then they should maintain it. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] two small bugs in zc.relationship
Markus Kemmerling wrote: But I wouldn't have expected a non built-in type, that *also* supports the mapping API, to be considered as `False` as long as the mapping is empty ... Built-in or otherwise, empty containers are almost universally false in Python. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] package branches
Gary Poster wrote: In that case, would what I released (except that I used -dev rather than dev) be correct? Yep. And those that only want final releases would be required to say so when invoking setuptools (or buildout). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zc.twist backward compatability
We don't think anyone is using it, but if you are, be warned that the zc.twist trunk is now not backward compatible in that you can no longer pass mvcc, version, or synch arguments to get_connection. Now back to your regularly scheduled programming. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Test failure in BuddyDemoLayer on trunk
Test failure in BuddyDemoLayer on trunk:
(pasted as a quotation in an attempt to avoid wrapping)
Running buddydemo.ftests.BuddyDemoLayer tests:
Set up buddydemo.ftests.BuddyDemoLayer in 1.012 seconds.
Error in test test_buddy_display (buddydemo.ftests.Test)
Traceback (most recent call last):
File /home/benji/Python-2.4.4/lib/python2.4/unittest.py, line 260, in run
testMethod()
File /home/benji/workspace/zope3/3/src/buddydemo/ftests.py, line 22, in
test_buddy_display
response = self.publish('/bob')
File /home/benji/workspace/zope3/3/src/zope/app/testing/functional.py, line
455, in publish
publish(request, handle_errors=handle_errors)
File /home/benji/workspace/zope3/3/src/zope/publisher/publish.py, line 130,
in publish
obj = request.traverse(obj)
File /home/benji/workspace/zope3/3/src/zope/publisher/browser.py, line 513,
in traverse
ob = super(BrowserRequest, self).traverse(obj)
File /home/benji/workspace/zope3/3/src/zope/publisher/http.py, line 451, in
traverse
ob = super(HTTPRequest, self).traverse(obj)
File /home/benji/workspace/zope3/3/src/zope/publisher/base.py, line 263, in
traverse
obj = publication.traverseName(self, obj, entry_name)
File
/home/benji/workspace/zope3/3/src/zope/app/publication/publicationtraverse.py,
line 61, in traverseName
ob2 = adapter.publishTraverse(request, nm)
File /home/benji/workspace/zope3/3/src/zope/app/container/traversal.py,
line 72, in publishTraverse
return self.context[name]
Unauthorized: (zope.app.folder.folder.Folder object at 0xb3592f6c,
'__getitem__', 'zope.View')
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Testing ZODB in Python2.5.
nikhil n wrote: ZODB shows an error when tested with python2.5.(http://zope3.pastey.net/52960) I think Python 2.5 unified long and normal integer and this caused the error. Is it enough that we add a renormalizer in testrunner.py? Looks like it to me, but you should ask the real experts at [EMAIL PROTECTED] -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] A thought on backward compatibility and minimum versions
Jim Fulton wrote: In thinking about how we might specify that we want to depend on major versions but sometimes need to specify minimum versions, the following occurred to me: I really like it. Of course we can do it without new syntax (unless I'm missing something), but the syntax would help a lot in making the intent clear. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: egg version numbers and zope releases
Jim Fulton wrote: It's actually worse than that. 2.0 would admit 2.0a1. :) You'd probably need something like 1.99. I can deal with spelling dependencies on major version X as = X.999. Even if developers remembered, it would be icky to have to spell out something like =3.4 =3.99 on everwhere. Not as icky (IMHO) as having distribution names with embedded major version numbers. I'm interested in other people's opinions here. Maybe there is some kind of dependency syntax that reads well that means I want this major version. Can you think of a syntax that is actually nicer than foo2? I can think of a syntax, but don't know if setuptools supports it. Perhaps I should look that up. But I wont. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.app.testing/trunk/src/zope/app/testing/functional.py fix bug in setter method of base_storage, i couldnt be set because of a typo
Bernd Dorn wrote:
Log message for revision 75826:
fix bug in setter method of base_storage, i couldnt be set because of a typo
A part of this fix should be adding a test that fails without this change.
Changed:
U zope.app.testing/trunk/src/zope/app/testing/functional.py
-=-
Modified: zope.app.testing/trunk/src/zope/app/testing/functional.py
===
--- zope.app.testing/trunk/src/zope/app/testing/functional.py 2007-05-17
23:18:19 UTC (rev 75825)
+++ zope.app.testing/trunk/src/zope/app/testing/functional.py 2007-05-18
08:15:27 UTC (rev 75826)
@@ -225,7 +225,7 @@
return self._base_storages[self._database_names[0]]
def _set_base_storage(self, value):
-if len(self._database_name)!=1:
+if len(self._database_names)!=1:
raise AttributeError('base_storage')
self._base_storages[self._database_names[0]] = value
___
Checkins mailing list
[EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/checkins
--
Benji York
Senior Software Engineer
Zope Corporation
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Launchpad Bug Emails
Marius Gedminas wrote: Launchpad lets you merge user accounts: Thanks! When I tried I got an Oops message. I'll give them time to fix it and try again later. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Launchpad Bug Emails
Philipp von Weitershausen wrote: A quick check revealed that you don't appear to be a team member. I would've changed that except that Launchpad seems to know two Benji Yorks :/. Yeah, I signed up with my personal email before we started using Launchpad for Zope 3 and then later signed up with my work email not remembering the other account. So why don't you apply for the membership in the zope3-dev team and I'll approve you right away :) I /think/ I've done what you said. Not Launchpad savvy enough to be sure. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Launchpad Bug Emails
I don't recall seeing automated Launchpad bug reports being emailed to zope3-dev, and couldn't find any with a quick search of my archive. Am I missing something, is this broken, or perhaps was it decided that such emails were undesirable? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot for all buildout projects
Christian Theune wrote: buildout alread did not report an error correctly at some point, but the next step currently breaks then, so it's only a minor glitch. That sounds like https://bugs.launchpad.net/bugs/113085. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tracking satellite project's trunks
Christian Theune wrote: Same here. I'm feeling like I'm not yet understanding what the trunk will be used like. I'm wondering if we need to maintain a Zope 3 project with any code in it at all (or nearly so). Could Zope 3 just be a buildout with a configuration that creates a Zope 3 application with a bunch of stock components. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] SHA1Password manager, add a pinch of salt
Giovannetti, Mark wrote: I like that update. However, it would fail authentication on stored lengths less than 40. Yes, I know that a length less than 40 would mean an anomalous stored password, but at least we guarantee a blank '' salt, rather than the possibility of getting some of the last hex digits of the stored password due to list wrap around. Might make debugging a problem just a little easier, you never know. How about putting the salt on the end of the stored value. Then fetching the salt would look like this: salt = storedPassword[40:] That way if the stored value was less than 40 characters, the salt would be the empty string. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] working towards 3.4 alpha release
Christian Theune wrote: I noticed that the buildbots have not run a successfull Zope 3 trunk build since March 25. :( The only builder that is configured to run the trunk and is currently on-line is zc-buildbot, and it would appear to be running the tests with every trunk check-in. OTOH, the 3.2, and 3.3 branches are broken and have been for quite some time. Sidebar: when trying to kick off a run for those two branches those two builders started exhibiting assertion errors, I'm looking into why that is. Most of the clients are broken. The single Windows slave that is purple is a result of bugs in twisted/buildbot. Hopefully newer versions don't have these problems. (We currently run 0.6.6, 0.7.5 is the latest). I don't have time to fight with upgrading at the moment. Two others are off-line, see the nagging section below. ;) The one at ZC is good but hasn't been run for quite a while. zc-buildout appears to run the trunk tests with every check-in. Is that the one you are referring to? The 3.2 and 3.3 tests failed the last time they were manually run. I don't think any changes have been made to those branches since, therefore not further runs have been triggered. Some of the rules that detect changes in the branches seem unreliable. Can you give an example? I propose to start make the clients do nightly builds. That's fine with me. I can get that configured pretty easily. Also, do we have someone who is the official 'client nagging guy' to remind people when their buildbot clients die? I'll be glad to nag anyone, but don't consider it a privilege available to only a few. The slave names are pretty clear (a couple could be clearer), so anyone can get a good nag in once and a while. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list [EMAIL PROTECTED] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
[EMAIL PROTECTED] wrote: The Buildbot has detected a failed build of Zope3 trunk 2.4 FreeBSD tmiddleton. This is caused by a ZODB test failure regarding blobs. zodb-dev has been alerted. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] 3.2 branch tests failing
It looks like this has been going on for a while: http://buildbot.zope.org/Zope3%20branches%203.2%202.4%20Windows%202000%20zc-bbwin/builds/163/test_2/0 Apparently someone changed the capitalization of the HTTP auth relm without running the tests. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Proposal for optimized Blob handling
Dieter Maurer wrote: Python's os.link creates a hard link which will only work if source and destination are on the same file system. ...and is also not available on Windows. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Why is the testrunner running with the --profile option ?
Michael Haubenwallner wrote: Just for the record, the problem is created by the ubuntu diffs that where automatically installed with the python2.4-minimal package That is one of the more repugnant things I've seen a distribution force on their users in quite some time. I intent to complain to the Ubuntu team. You are completely right and there is no problem with python installed from source. These sorts of games are one of the reasons I (and many others) strongly prefer working with Pythons that we built ourselves. Thanks for the good work running this to ground. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why is the testrunner running with the --profile option ?
Michael Haubenwallner wrote: Why is the testrunner running with the --profile option ? I did not set it. I understand that profiling should be disabled if hotshot cannot be imported. Running (from a svn checkout) python test.py -s zope.anypackage Works for me. ImportError: No module named profile please install the python2.4-profiler package zope.testing never imports profile. It uses hotshot, but that import is protected by a try/except because some distributions don't include hotshot. Perhaps we could help more if you included the full traceback of the above exception. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Why is the testrunner running with the --profile option ?
Michael Haubenwallner wrote: It is like Marius Gedminas said earlier in his response: just install python2.4-profiler package and it works. I'm glad that solved your particular problem. zope.testing is supposed to work without hotshot (and therefore its dependencies like profile), so I'd like to figure out why it's not working correctly. hotshot.stats throws the ImportException and then exits; there is no traceback available. I think, the only way to catch this case is trying to import profile in testrunner itself before importing hotshot.stats. This is what has me confused; the only imports of hotshot and hotshot.stats are protected by try/excepts. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.cachedescriptors outdated
Philipp von Weitershausen wrote: I once mused about this and came up with rwproperty offtopicWhich is quite nice./offtopic -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3.3.1
Philipp von Weitershausen wrote: P.S.: What will it take to get the buildbot, especially the Windows one, working again? Short-term: I've restarted those slaves, as the particular version of buildbot we use is flaky on Windows and will go purple (the color the waterfall view shows for the builder status) and never come back. Long-term: attempt to upgrade to the current version of buildbot that (hopefully) is more stable on Windows. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3.3.1
Sidnei da Silva wrote: FWIW, under 'heavy load' the master might kick out the slave [1] [2] because it doesn't get a ping response in time. Not sure if that's what you are experiencing. That might be it, I've made the change described in that thread to the master, we'll see if it helps. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.mimetype / z3c.filetype
Luis De la Parra wrote: I don't know if there is some licesing or some other kind of political issues ( zope vs z3c ), but IMVHO it would be great if the two packages were merged. I'm not really a zope developer yet, but if the maintainers of those packs are interested, I could try to help with that. Interest is abundant; time and motivation are lacking. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner
Wouldn't that change just defer the error until that function is called? (which the testbrowser tests do) -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [zope.testing] testbrowser/browser importing 'test' conflicts with Zope 2 testrunner
Andreas Jung wrote: --On 19. Januar 2007 14:41:53 -0500 Benji York [EMAIL PROTECTED] wrote: Wouldn't that change just defer the error until that function is called? (which the testbrowser tests do) The patch solves my problem and the testbrowser tests pass. I suspect that means the tests are insufficient, but I'm just pragmatic enough to be persuaded the patch should go in (with a comment as to why that import is done there). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: SVN: zope.app.annotation/ Add zope.app.annotation as a top-level package.
Philipp von Weitershausen wrote: I suggest we come up with a prioritized list instead of alphabetical. +1 Baiju M wrote: We can eggify all packages except those in Spring cleanup proposal [1] Sure, we *can*, but I think it's a lot of work and we don't necessarily have to do all of them. That isn't to say I don't appreciate your work going into this effort, I just think it could be used more effectively ;) This /is/ to say that I appreciate your work on this, Baiju. :) -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re[4]: Zope 3.3.1
Adam Groszer wrote: Buildbot seems to sleep these days. Indeed. The Windows version tends to fall over and I've been too busy to notice of late. I wish I had time to try a newer version, but last time I did that Twisted had removed support for one of the APIs buildbot uses from their Windows version and I had to downgrade. I'll kick it when I have physical access tomorrow. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py --list-modules
Marius Gedminas wrote: On Fri, Jan 12, 2007 at 05:17:18PM -0500, Benji York wrote: OTOH, being not very accurate would make the feature as implemented a bit of an attractive nuisance. I phrased it badly. s/It is not very accurate/It may not match user expectations/. Ahh, I see now. As for the question then, I would prefer it list only the tests that would be run. Perhaps a separate switch could be provided that would list all tests found. Then a person trying to debug their test not being run would know if the test runner found it or not, and if so, if a filter precluded it from running. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: test.py --list-modules
Marius Gedminas wrote: I have implemented a --list-modules option in a branch. It causes the test runner to apply package and module name filters, and then print the list of Python module names that would be imported. It is very fast because it doesn't actually import the modules. It is not very accurate because it does not pay attention to test name patterns or layer filtering. Would this option be useful to anybody? If its output were identical to the tests that were actually going to be selected, then I think it'd be worth including. OTOH, being not very accurate would make the feature as implemented a bit of an attractive nuisance. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: Zope3/trunk/src/zope/app/renderer/rest.py added optional parameter to the render method to allow overriding of the
Jodok Batlogg wrote: Log message for revision 71853: added optional parameter to the render method to allow overriding of the default settings for rendering rest files. I would suggest allowing the caller to override only the options they care to by doing a .update of the settings dict with the passed-in overrides. That way if new options are added in the future, their code won't break. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.selenium test isolation
Christian Theune wrote: I propose to add an ultimate pop at the beginning of each test, to ensure consistency/isolation at those points. Where ultimate pop means to remove all stacked demostorages added by previous tests? If so, sounds good. I do worry a little about that hiding mismatched push/pop operations in non-failing tests. Perhaps the ultimate pop could generate a selenium error if there was anything there to pop. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Tests failing
The tests are failing on the trunk, 3.2, and 3.3 branches. Apparently because of the recent addition of a Cache-Control header. See the buildbot for details: http://buildbot.zope.org -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RE: [SpringCleaning07]
Stephan Richter wrote: - zope.app.renderer You can safely remove it from the base tree. It was not such a big success as I was hoping for. Other approaches are easier. Note that wiki and bugtracker still use this code, so it should be still available for those packages. I believe apidoc uses this package. And having looked at it, I generally like the package itself (and have begun using it in a small project), but if apidoc doesn't really need it, moving it to a separate project in the repo would be fine. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zc.recipe.zope3instance/branches/gocept-zconf-slug-dev/src/zc/recipe/zope3instance/__init__.py ignoring .svn in skeleton
Christian Zagrodnick wrote: Log message for revision 71542: ignoring .svn in skeleton Might I suggest that any file with a leading dot be ignored. That would keep us from having to add exceptions for other revision control systems (at least CVS, bzr, and Mercurial use dot files in one way or another). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Chris Withers wrote: Benji York wrote: Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. Really? Now this is a use case I hadn't thought of.. can you give me some examples of where you've run into this? I don't know that I have, but the component system doesn't preclude it so anything we come up with will have to take it into effect. This seems somewhat analogous to a Python object being given multiple names. In that case too, there is no way for the object to know what it's names are. Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the notion of an object knowing its own name. Certainly in Zope 2, everything has an id or .getId(). That pattern evolved for a reason ;-) Sure, where everything is defined as content space objects, other objects more rarely. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Can an adapter find out what name it was registered for?
Chris Withers wrote: I don't think it'll be a common pattern, but it doesn't feel right to me that a named adapter (ie: one registered with a specific name) has no way of finding out what name it has been registered with... Because the same adapter can be registered more than once, it would actually need to find out all the names with which it was registered. This seems somewhat analogous to a Python object being given multiple names. In that case too, there is no way for the object to know what it's names are. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: browser widgets: items widgets and label tags
yuppie wrote: Adding additional complexity for getting the label issue perfectly right doesn't fit much to the rest of the code. And I doubt any browser will have trouble with 'for' attributes pointing to a non-control element. The for attributes in labels are used heavily in zope.testbrowser functional tests. If the human readable labels no longer correctly identify the controls, control IDs or names would have to be used instead, which is not conducive to good tests. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] PyCon 2007 web frameworks panel
Titus Brown is putting together a web framework panel for the next PyCon: http://us.pycon.org/TX2007/WebFrameworksPanel. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Big Problem with FTP in Zope 3.3.0, seems to be the result of using `v = self.get(name, self); if v is self...` in a land where Proxy objects can kill identity comparison
Jeff Shell wrote: [lots of stuff I don't know much about, so I won't comment on] Is there any reason why the ``_marker = object() get(..., default=_marker)`` paradigm isn't used? After encountering this, I am rather uneasy about the number of places in which I see this self as default marker check paradigm. My biggest unease comes from not knowing proxies and when things are proxied and when they're not and when I have to be careful about them and when I don't. I like the marker flavor of the pattern better too, but for a different reason. When I see something in the second argument to the get, I don't know if it's /really/ the default, or if it's just being used as a placeholder so I have to investigate to find out. I prefer the more explicit version. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.fssync/trunk/ Initial commit of zope.fssync for eggification.
Baiju M wrote: On 10/29/06, Benji York [EMAIL PROTECTED] wrote: I'm really glad to see so much work being done on eggification, but am a little concerned as to the mechanics. I'm worried that if dozens of packages are separated out before they are actually knit into Zope proper, we'll get drift between the two. It would seem to make more sense to eggify one or a few packages and get them properly working in the core, and then go from there. zope.fssync and some other packages are not distributed with Zope 3. That doesn't answer my question, for two reasons. There are still duplicate copies of the code. I suspect we should be removing the code from the core tree as the packages are separated out (of course we have to have a story for people who use those packages from the trunk first). Also, there are several packages that have been copied that /are/ included in the core. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Checkins] SVN: zope.fssync/trunk/ Initial commit of zope.fssync for eggification.
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benji York wrote: Baiju M wrote: On 10/29/06, Benji York [EMAIL PROTECTED] wrote: I'm really glad to see so much work being done on eggification, but am a little concerned as to the mechanics. I'm worried that if dozens of packages are separated out before they are actually knit into Zope proper, we'll get drift between the two. It would seem to make more sense to eggify one or a few packages and get them properly working in the core, and then go from there. zope.fssync and some other packages are not distributed with Zope 3. That doesn't answer my question, for two reasons. There are still duplicate copies of the code. I suspect we should be removing the code from the core tree as the packages are separated out (of course we have to have a story for people who use those packages from the trunk first). Leave an 'svn:external' behind to the new location, perhaps with a 'DEPRECATED.txt' file stating when the external would go away? That's fine with me. I'm not debating how it should be done, just that /some/ migration planning should be done. I don't see any evidence of externals (or anything else) being added to the trunk. Maybe I'm overreacting (as little reacting as I'm doing). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The z3c.javascript package
Fred Drake wrote: My first guess is that this is a licensing-related issue; is that right? I don't know, but doubt it. Both MochiKit and dojo are available under very permissive licenses. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: The z3c.javascript package
Gary Poster wrote: On Oct 25, 2006, at 10:46 AM, Benji York wrote: Fred Drake wrote: My first guess is that this is a licensing-related issue; is that right? I don't know, but doubt it. Both MochiKit and dojo are available under very permissive licenses. Right, but currently only ZC employees are allowed to check in non- ZPL code not written by themselves, and AFAIK that policy hasn't been settled on for once the repo is moved to the ZF. Oh, indeed. You'd think I would remember that, being the license whiner that I am. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: RFC: Zope Configuration Egg Support
Jim Fulton wrote: Perhaps we should change the package option so that it uses the pkg_resources API to load ZCML files from packages. +1 I'd prefer not having to specify if the source was an egg or just a normal package. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope Configuration Processing and Side Effects
Simon Michael wrote: Baiju M wrote: Let's use new wiki now onwards. Sooner or later this will be wiki.zope.org We have to make current wiki read only very soon. How do you feel about this folks ? I'd like to make the old zope 3 wiki read-only and activate the subscriptions on the new one. +1 -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Set 'svn:keywords Id' to *.py files
Baiju M wrote: Hi all, Few weeks back when I added a new file I forgot to set 'svn:keywords Id', but I added '$Id$' in that file. I thought there will be few more files like that, so I tried this command: This is where I refrain from venting my hatred of $Id$. Oops, well almost. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] how to override zope.app.securitypolicy sanely
Adam Groszer wrote: For our application the standard securitypolicy was fine. Until today. Now a requirement came up that the object permissions have to depend _also_ on an object state (the object's property). zc.sharing might be a good fit. You'll have to change the sharing settings on the objects when their state changes, but that's not too onerous. http://svn.zope.org/zc.sharing/trunk/src/zc/sharing/ -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
