Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
On 24/08/2009 Chris Withers wrote: > > that's important for distributors who want to distribute generic > > software, not user specific instance setups. > > Distributors just want a tarball or similar, let them use > zc.sourcerelease and have a slightly different buildout.cfg, or even > default.cfg, which uses that tarball as the source of eggs rather than > PyPI... do you have any example code on how to do that? greetings, jonas signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hello, On Fri, Aug 14, 2009, Jim Fulton wrote: > On Fri, Aug 14, 2009 at 12:30 PM, Jonas Meurer wrote: > ... > > zope2 releases based on buildout make it very hard for distributors to > > package zope2. especially as zope2 requires > > from what i know about buildout (and that's not much), it either requires > > a working internet connection or a local mirror with exact versions of > > all required python eggs. > > > > i would highly appreciate a final release tarball which includes all > > required python library/module eggs. > > This ought to be easy using zc.sourcerelease. We (zc) use it to make > self-contained tar balls from which we build rpms. do you have any examples how to use zc.sourcerelease for that purpose? i see that this is the right utility, but i fail to understand how it works up to now. the whole buildout stuff is fairly new to me. it would be great if you had an example script with zc.sourcerelease which creates a source tarball for zope2.12. if i got it right i need buildout.cfg for zc.sourcerelease which describes how to create the tarball. and then i need a second buildout.cfg for zope2.12 which describes how to actually build zope2.12 from the sources that zc.sourcerelease put together, right? greetings, and thanks in advance, jonas signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.publisher refactoring status
2009/8/25 Martijn Faassen : > See my comment on naming. I think we should call 'zope.menu', > 'zope.page', 'zope.resource'. See my answer there :-) >> * zope.ptresource - the page template resource that was moved into a >> separate package to make zope.browserresource independent from >> zope.pagetemplate. it's now a plugin for zope.browserresource - a >> custom resource factory, registered for "pt", "zpt" and "html" >> extensions. > > Was it registered for these extensions already? In particular I'm > wondering about the 'html' extension - I can see use cases to want to > publish non-page template HTML files as static resources. The DirectoryResource was creating page template resources for these extensions, so I just copied the behaviour. I also see the case when simple static HTMLs are needed, I think those cases are most, actually. But pagetemplate resources will work for non-templated HTMLs as well, and people can simply not include zope.ptresource configure.zcml and configure the resource factory for extensions they need. I guess most people won't even install zope.ptresource though, as it's not very useful. ZRT resources are more appropriate for dynamic css's and javascripts, so I think users will prefer it (BTW, it also needs to be adapted for new package). >> Second, the "browser:defaultView" and "browser:defaultSkin" >> directives. The functionality of default views and default skins is >> currently contained in zope.publisher, and these directives only >> provide a way to configure default view/skin via ZCML. I think that >> these directives should be moved to zope.publisher as well, since it >> seems the right place for them and the move won't introduce extra >> dependencies for zope.publisher. > zope.publisher indeed already depends, at least indirectly, on > zope.configuration. It doesn't define any ZCML directives at this point > though, which makes me a bit wary. Then again, zope.security does, and > zope.publisher depends on it. So I think this is all right. Okay, that's done :-) >> Third, the "xmlrpc:view" directive and the XML-RPC method publisher. >> It's a nice thing, but people doesn't seem to be interested very much >> in XML-RPC these days. Also, it seems that zope.publisher will be >> refactored soon, so the future of xmlrpc modules is not clear. I see >> two options for this thing: >> >> a) Extract it into the new, "zope.xmlrpc" module. >> b) Leave it there as is. >> >> If noone demonstrates interest in discussing the xmlrpc, I'll probably >> choose option b :-) > > Grok at least can't just lose its XML-RPC support, and we'd like to stop > importing zope.app.publisher if we can. While I think most people have > moved on to using other things than XML-RPC, I do think there's a lot of > code out there that does use XML-RPC, and it's so convenient I suspect > more code will be written in the foreseeable future. > > I therefore would like to see a zope.xmlrpc module. I think there is > code in other packages as well that could be moved in here. We do need > to think about the import situation however. > > That said, we shouldn't wait for this to be resolved to merge the other > changes into the Zope Toolkit. I'll leave it there for now, until XMLRPC and FTP refactorings. There's some PITA with functional tests for this module (or it's just me with not enough experience, whatever), so it'll take some time. I'd like other changes to be merged soon. > Finally, it'd be nice if we could give the new KGS system a workout by > testing things with that. I hope you can involve Jim in this discussion. > Then once we have a way of working figured out, it's important we also > record this in the ZTK documentation. Sorry, I also didn't catch up with the list recently, so I don't know about the "new KGS system" yet. :-) I'll read about it later. -- WBR, Dan Korostelev ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in ZTK
Cool. I just updated the .rst file. Someone else has to update the web site. :) Jim On Tue, Aug 25, 2009 at 12:17 PM, Martijn Faassen wrote: > Jim Fulton wrote: >> On Sat, Jul 4, 2009 at 7:33 AM, Christian Theune wrote: >>> So, if you see that a package is missing or is classified in the wrong >>> way, then please speak up. >> >> I think zope.wfmc and zope.app.wfmc should be removed. I don't think >> they're widely used. I don't use them any more and I wrote them. :) >> I'm not personally maintaining them. > > +1 to removing those. > >> I think zope.xmlpickle should be removed. I don't think it's widely >> used in Zope applications. I do find it useful from time to time for >> looking at pickles and plan to maintain it in the future, but don't >> think it should be in the ZTK. > > +1 as well. > > Regards, > > Martijn > > ___ > Zope-Dev maillist - zope-...@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 ) > -- Jim Fulton ___ 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 Tue, Aug 25, 2009 at 12:21 PM, Martijn Faassen wrote: ... > That sounds reasonable, as long as it is documented. I got confused at > first about the term 'test branch', but you just mean a non-maintenance > branch of a package to do some development on. The special thing is here > that we'd wait for the buildbot to do the testing on different platforms. No, I meant a dedicated staging branch. Basically, work would be done on a development branch, them merged to a stage branch and after all tests pass, merged to trunk. > I wonder whether we couldn't use snakebite.org infrastructure for the > testing. I'd be good if someone could manually trigger a cross-platform > cross-interpreter test instead of having to wait for buildbots. Is snakebite real? That page has said "coming soon" for a long time. Jim -- Jim Fulton ___ 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.app.publisher refactoring status
Hey Dan, See also my feedback in the original thread. Dan Korostelev wrote: > Four new packages have been introduced: See my comment on naming. I think we should call 'zope.menu', 'zope.page', 'zope.resource'. > * zope.browsermenu - browser menu system, without any changes. :-) > > * zope.browserpage - browser:page directive and friends. the > directives was changed to support menu item registration only when > zope.browsermenu is available, simply ignoring (and raising a warning) > the "menu" argument otherwise. Sounds good. > * zope.browserresource - resource system and browser:resource > directive and friends. file-based resources now supports pluggable > resource class lookup based on file extension (implementation based on > this patch - https://bugs.launchpad.net/zope3/+bug/98459). this allows > to separate pagetemplate resources into another package as well as > support registering specific resource factories for some extensions > (.zrt for example). Cool. > * zope.ptresource - the page template resource that was moved into a > separate package to make zope.browserresource independent from > zope.pagetemplate. it's now a plugin for zope.browserresource - a > custom resource factory, registered for "pt", "zpt" and "html" > extensions. Was it registered for these extensions already? In particular I'm wondering about the 'html' extension - I can see use cases to want to publish non-page template HTML files as static resources. [snip] > Things left in zope.app.publisher are still to be discussed. > > First, the "Browser Skins" vocabulary - a vocabulary of > IBrowserSkinType utilities. It could be moved to zope.publisher, but > it introduces dependency on zope.componentvocabulary, which is not > needed for zope.publisher currently. So there's three options to > choose from: > > a) Move it to zope.publisher, introducing a dependency on > zope.componentvocabulary for it. > b) Move it to zope.publisher, rewriting the vocabulary to use > zope.schema's SimpleVocabulary and not introducing dependency on > zope.componentvocabulary. > c) Leave it there as is. I think, that it's a nice option, since > "Browser Skins" vocabulary doesn't seem to be used anywhere by other > zope packages and can be easily recreated if someone will need it. I'm okay with a) and c). It's indeed not much code, though on the other hand it'd be nice to make it reusable anyway. > Second, the "browser:defaultView" and "browser:defaultSkin" > directives. The functionality of default views and default skins is > currently contained in zope.publisher, and these directives only > provide a way to configure default view/skin via ZCML. I think that > these directives should be moved to zope.publisher as well, since it > seems the right place for them and the move won't introduce extra > dependencies for zope.publisher. zope.publisher indeed already depends, at least indirectly, on zope.configuration. It doesn't define any ZCML directives at this point though, which makes me a bit wary. Then again, zope.security does, and zope.publisher depends on it. So I think this is all right. > Third, the "xmlrpc:view" directive and the XML-RPC method publisher. > It's a nice thing, but people doesn't seem to be interested very much > in XML-RPC these days. Also, it seems that zope.publisher will be > refactored soon, so the future of xmlrpc modules is not clear. I see > two options for this thing: > > a) Extract it into the new, "zope.xmlrpc" module. > b) Leave it there as is. > > If noone demonstrates interest in discussing the xmlrpc, I'll probably > choose option b :-) Grok at least can't just lose its XML-RPC support, and we'd like to stop importing zope.app.publisher if we can. While I think most people have moved on to using other things than XML-RPC, I do think there's a lot of code out there that does use XML-RPC, and it's so convenient I suspect more code will be written in the foreseeable future. I therefore would like to see a zope.xmlrpc module. I think there is code in other packages as well that could be moved in here. We do need to think about the import situation however. That said, we shouldn't wait for this to be resolved to merge the other changes into the Zope Toolkit. Finally, it'd be nice if we could give the new KGS system a workout by testing things with that. I hope you can involve Jim in this discussion. Then once we have a way of working figured out, it's important we also record this in the ZTK documentation. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IRC discussion about testing
On Tuesday 25 August 2009, Martijn Faassen wrote: > > We can use such a list to extract more information from included > > packages. For example, I have a script to extract all CHANGES.txt entries > > in comparison to an older KGS version. > > Ah, nice use case. In fact I also have a script that parses CHANGES.txt > entries and turns them into atom feeds, which could then be merged. I > intended to use this to monitor the development of the KGS. See zope.release for a full list of scripts that I originally developed for the KGS. I really wish that we are not loosing this sort of capabilities, since it would make the release process a lengthy task again. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IRC discussion about testing
Stephan Richter wrote: > On Wednesday 12 August 2009, Jim Fulton wrote: >> I'm not sure why this all has to be computer readable. What is the >> use case for computer readable knowledge of whether a package is in >> the kgs or just used to test it? What is the need for computer >> readable information about where the package is being developed. > > We can use such a list to extract more information from included packages. > For > example, I have a script to extract all CHANGES.txt entries in comparison to > an older KGS version. Ah, nice use case. In fact I also have a script that parses CHANGES.txt entries and turns them into atom feeds, which could then be merged. I intended to use this to monitor the development of the KGS. Regards, Martijn ___ 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: zope.app.publisher refactoring
2009/8/25 Martijn Faassen : > You have zope.browsermenu, zope.browserpage, zope.browserresource. I > propose instead we name them zope.menu, zope.page and zope.resource. -1 These things are really only for browser, and ZCML directives are in "browser" namespace, while, for example, "zope.resource" is a quite abstract name that could be taken by more appropriate package in future. > I think we can safely claim these names in the 'zope' namespace as > these *are* the Zope Toolkit menu, page and resource > implementations. I'm not sure if they are "reusable without having to buy into the rest of the Zope Toolkit". Currently these packages have a note that they are not reusable, as recommended in steering group decisions list, because they depend on the publishing system, which is a really large part. -- WBR, Dan Korostelev ___ 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))
Hi there, Fabio Tranchitella wrote: [snip] > Will we have an "official" buildbot instance somewhere under the zope.org > domain? In this case, I'm willing to administer and maintain it, if nobody > else steps in. I'd be happy to see this. We can do this with a DNS thing (buildout.zope.org) or we can actually run something on zope.org if someone explains what should be done to Jens. (the minimal info of: this script needs to be run every n hours). Regards, Martijn ___ 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: zope.app.publisher refactoring
Hi there, Here are some steering-groupish responses. General note: I'm quite enthusiastic about the general plan to clean up zope.app.publisher! Thanks for bringing this up! Dan Korostelev wrote: > Menu mechanism (the browser:menuItem directive and friends) - move > this to the new "zope.browsermenu" package. This should be easy as > nothing else in zope.app.publisher seem to depend on menus. +1. You noted elsewhere there's a dependency from the browser:page directive on this too. If you can make it smart enough in a simple way to only depend on it if zope.browsermenu is actually installed, let's do that. > Browser view directives (browser:page and friends) - move this to some > "zope.browserpage" package and make its structure more clean, so > people could understand the magic of browser page class generation. > :-) +1. > BrowserSkinsVocabulary - this can be moved to zope.publisher.browser > and rewritten with zope.schema's SimpleVocabulary not to introduce > dependency on zope.componentvocabulary. As noted elsewhere, let's keep the dependency on zope.componentvocabulary for now, unless this introduces more dependencies to zope.publisher in *addition* to the introduction of zope.componentvocabulary itself. > ManagementViewSelector (the @@SelectedManagementView.html view) - > leave it there as is. +1. Anything ZMI-ish stays. > Resource mechanism (files, directories, etc.) - probably the most > complicated code, but it should be easy to move it to the new > "zope.browserresource" package. One problem is with > PageTemplateResource that introduces a dependency on > zope.pagetemplate. It should probably moved to another package, like > "zope.ptresource" and made dependent on z3c.ptcompat to support > chameleon engine. +1 on this strategy, also about factoring out zope.ptresource. This is a less commonly used resource anyway as far as I know, as resources are generally assumed to be static. > ModifiableBrowserLanguages implementation - move to > zope.publisher.browser. It's the useful thing that won't introduce any > new dependencies. +1 > "date" fieldconverter - I don't think anyone uses it, I'd leave it > there as is and forget about it :) I'm not sure about fieldconverters in general. Shane worked on a WSGI implementation of fieldconverters instead. We could move it zope.publisher fairly easily, except that it depends on parseDateTime in zope.datetime. Let's leave it there for the time being, and see what happens. We can always move it later. > http.zcml - this file contains security declarations for > zope.publisher's HTTP-related classes. move them to zope.publisher. +1 > xmlprc As noted elsewhere, I'd be nice if we had a zope.xmlrpc which consolidated all the XML-RPC related code into a single package. Same applies for FTP support. We don't need to fully figure this out yet to start pulling some of the other stuff out first, though. > ILogin, ILogout from zope.app.publisher.interfaces.http - looks like > these don't really mean anything and are used only in > zope.app.security. I'd move them to zope.app.security even without BBB > imports (not to make zope.app.publisher dependent on > zope.app.security), but maybe I just don't know something about them? > :) I'll follow your decision here, I saw some further discussion elsewhere.. > That's all for now. I'd like to see some > comments/propositions/objections before I start. Also, maybe there are > more beautiful names for new packages? Concerning naming: You have zope.browsermenu, zope.browserpage, zope.browserresource. I propose instead we name them zope.menu, zope.page and zope.resource. I think we can safely claim these names in the 'zope' namespace as these *are* the Zope Toolkit menu, page and resource implementations. If we can consolidate the XML-RPC and FTP-related code into separate packages as well, we'd end up with zope.xmlrpc and zope.ftp too. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK and Python 2.6, zope.app.zcmlfiles and zope.app.security globalmodules.zcml
Hey, Jim Fulton wrote: [snip] > A. Suck it up and live with the deprecation warnings until we get rid > of zope.app.zcmlfiles > B. Remove the security declaration for mhlib from globalmodules.zcml. > Is anyone actually building web applications that publish MH mail > folders? > C. Stop including globalmodules.zcml from zope.app.zcmlfiles > > Opinions? FWIW, I vote for B. +1 for B too. Regards, Martijn ___ 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: zope.app.publisher refactoring
Dan Korostelev wrote: > 2009/8/24 Stephan Richter : >> On Friday 21 August 2009, Dan Korostelev wrote: >>> BrowserSkinsVocabulary - this can be moved to zope.publisher.browser >>> and rewritten with zope.schema's SimpleVocabulary not to introduce >>> dependency on zope.componentvocabulary. >> -1. Why? The reason we wrote the zope.componentvocabulary code originally was >> exactly to avoid the constant reimplementation of that code. > > Well, the only reason is that zope.publisher currently doesn't depend > on zope.componentvocabulary. But it doesn't matter for me personally, > so if steering group decides that it's okay to add a dependency on > zope.componentvocabulary to zope.publisher, I won't rewrite the > vocabulary with SimpleVocabulary :-) For the reasons of code stability let's rely on zope.componentvocabulary then, at least for now. zope.componentvocabulary doesn't look like it adds serious dependencies. Regards, Martijn ___ 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: zope.app.publisher refactoring
Dan Korostelev wrote: > 2009/8/21 Dan Korostelev : > >> Browser view directives (browser:page and friends) - move this to some >> "zope.browserpage" package and make its structure more clean, so >> people could understand the magic of browser page class generation. >> :-) > > Silly me, I forgot that browser page directives have the "menu" and > "title" arguments to integrate browser pages with menus! > > But I'd like to see browser pages usable without using that browser > menu implementation, so I want to discuss one more proposition: make > browser page directives smarter, so they wouldn't depend hadly on > menus and support menu item registration for pages only when > "zope.browsermenu" is installed (and raise an error if browsermenu is > not installed and user tried to use "menu" argument). This won't hurt > any current zope.app.publisher's users, but can confuse new users who > will be learning these zcml directives. But I am sure that good > documentation can help here. :-) +1 if we can make it smarter to break this dependency (but not too smart; I'm not sure how easy this would be). Regadrs, Martijn ___ 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: zope.app.publisher refactoring
Hey, Shane Hathaway wrote: [snip] > Few developers care about XML-RPC these days. Most web developers are > now working with REST, JSON, and other similar stuff. It's probably > best to move all XML-RPC artifacts, including those in zope.publisher, > to a single package, so that most developers can safely ignore the > XML-RPC code. +1 on this general direction. >> IFTPDirectoryPublisher interface - not sure what's this and where is >> it used. Probably should be moved to zope.publisher.interfaces.ftp as >> well. > > FTP is in the same boat as XML-RPC. Today, very few developers care to > provide a dynamic FTP view of anything. WebDAV usually wins over FTP > because adding SSL to WebDAV is easy. All FTP artifacts should move to > a separate package. +1 as well. I've recorded this information in the Zope Toolkit decisions document, just so we know where we're heading. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in ZTK
Jim Fulton wrote: > On Sat, Jul 4, 2009 at 7:33 AM, Christian Theune wrote: >> So, if you see that a package is missing or is classified in the wrong >> way, then please speak up. > > I think zope.wfmc and zope.app.wfmc should be removed. I don't think > they're widely used. I don't use them any more and I wrote them. :) > I'm not personally maintaining them. +1 to removing those. > I think zope.xmlpickle should be removed. I don't think it's widely > used in Zope applications. I do find it useful from time to time for > looking at pickles and plan to maintain it in the future, but don't > think it should be in the ZTK. +1 as well. Regards, Martijn ___ 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))
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. No ranges. If you want to update a version in your own app's buildout you should be able to override it, of course, but the KGS should be a fixed point. > We need to agree on the the process for updating the ZTK KGS. Here's > a rough sketch of what I think we need. > > - We need to create a test branch. > > - 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. > > - We maintain windows and linux buildbots (or equivalent) against both > the test branch and trunk for Python 2.4, 2.5 and 2.6. > > - 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. > > Thoughts? That sounds reasonable, as long as it is documented. I got confused at first about the term 'test branch', but you just mean a non-maintenance branch of a package to do some development on. The special thing is here that we'd wait for the buildbot to do the testing on different platforms. I wonder whether we couldn't use snakebite.org infrastructure for the testing. I'd be good if someone could manually trigger a cross-platform cross-interpreter test instead of having to wait for buildbots. Regards, Martijn ___ 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))
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. Ah, that's what my understanding was of Jim's term 'test branch', but now I realize I was wrong. Jim's "test branch" would be staging area for the trunk and only this staging area would get tested. Regards, Martijn ___ 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] UnicodeDecodeError problems with Zope 2.12.0b4
Takayuki Shimizukawa wrote:
> 2009/8/22 Chris Withers :
>> The first type of problem occurs when a form is submitted and the form
>> fields contain encoded strings. Somewhere down the line I get:
>
> The first type, I don't know.
>
>> The second type of problem only occurs in IE and Safari, where viewing a
>> page that contains some non-ascii-able data:
>
> The second type, (maybe) similer probrem reported to launchpad.
> https://bugs.launchpad.net/zope2/+bug/160968
>
>> - Why am I getting this decoding error only with these browsers? Firefox
>> and Chrome work just fine... Is the publisher doing something special
>> with a header these browsers send that IE and Safari are not? If so, how
>> do I make it do the "right thing" for IE and Safari?
>
> Are concerned that HTTP_ACCEPT_CHARSET http header will probably
> not be sent from client browser (IE6,7, Safari).
> When HTTP_ACCEPT_CHARSET not in HTTP request headers,
> zope.publisher use UTF-8 encoding for publishing.
Well, I just solved the problem with a large setdefaultencoding hammer :-)
Annoyingly, this required even more evil, since sitecustomize.py is no
longer found anywhere sensible in Python 2.5, so I ended up with a
buildout that looks like the following:
[buildout]
parts = instance
extends =
http://svn.zope.org/*checkout*/Zope/tags/2.12.0b4/versions.cfg?rev=102515
versions = versions
[versions]
zope2 = 2.12.0b4
[instance]
recipe = zc.recipe.egg
eggs = ${buildout:eggs}
interpreter = py
entry-points=
runzope=Zope2.Startup.run:run
zopectl=Zope2.Startup.zopectl:main
scripts = runzope zopectl
initialization =
import sys
reload(sys)
sys.setdefaultencoding('utf-8')
sys.argv[1:1] = ['-C','${buildout:directory}/etc/instance.conf']
Evil huh? ;-)
Hope this helps someone...
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] IRC discussion about testing
Jim Fulton wrote: >> I do think we need a computer readable system that includes information >> like this: >> >> * whether a project is in a KGS (such as for the ZTK) >> >> * whether a project is used to test a KGS (a package not in the ZTK but >> used to test whether changes don't induce breakage, let's say, >> grokcore.component) >> >> * the locked down version of the package. >> >> * where the *next* version of the locked down version is being >> developed. Generally this is the SVN trunk, but could be a stable branch. > > I'm not sure why this all has to be computer readable. What is the > use case for computer readable knowledge of whether a package is in > the kgs or just used to test it? Making it computer readable to get those packages in the KGS is not that useful, I imagine, though making it so could potentially see tools being developed. > What is the need for computer > readable information about where the package is being developed. That's a real usecase. There are tools that can already use this information, in particular mr.developer: http://pypi.python.org/pypi/mr.developer It's nice to be able to just get the relevant checkout of a package without having to hunt around trying to figure out where it is. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] List of packages in ZTK
Jim Fulton wrote: > On Tue, Aug 11, 2009 at 5:39 PM, Jim Fulton wrote: > ... >> Why is zope.ucol in the list? It's a pain to install (and thus test) >> because it needs ICU. > > BTW, I hope that zope.ucol isn't needed (when you need unicode > collation badly enough that you're willing to install ICU) anymore. I > wrote it when PyICU was a pain to install. I hear it's gotten easier > to install. +1 on removing zope.ucol from the list. Regards, Martijn ___ 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] Move implementation of getParent to zope.location?
Thomas Lotze wrote: > Martijn Faassen wrote: > >> One question to ask is whether getParent and getParents are used all over >> the place or just by zope.traversing. If they're only used by >> zope.traversing we might not want to move them to a more general place, >> but perhaps we can even see about removing them. > > getParent is used by a number of zope.app.* packages (apidoc, container, > dependable, onlinehelp, preference, rotterdam, pythonpage, workflow). Its > only other occurrence is in zope.traversing where it is defined, but not > used. > > getParents is used by zope.app.* packages as well (rotterdam, tree, > workflow) and definitions of it occur in zope.location and > zope.traversing, where it isn't used either, though. > > Seeing this now, I agree to removing the functions provided nobody objects > against removing parts of the API that might be depended on by client code > out there. (Both functions are actually exported by zope.traversing.api.) I think that means we can't remove it. I'd say move it. Regards, Martijn ___ 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] SVN: zope.publisher/trunk/ Moved dependency on zope.testing from install_requires to tests_require.
Jim Fulton wrote: > On Tue, Aug 11, 2009 at 8:02 AM, Martijn Faassen > wrote: [snip] >> Ah, that's cool. I take it it's not yet possible to do without the test >> extra entirely and let buildout rely on the test_require section? That >> way we could do without duplication. > > That's what Tres' setuptools plugin allows. It seems to me to be less > work to just repeat the information. Even then, you don't really have > to repeat it. > You can define the test requirements as a module-level variable and > then refer to the variable in both tests_require and the extras > definition. Sure, but someone needs to document it, otherwise this practice will never be adopted. Any progress on that? Regards, Martijn ___ 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.sendmail and testing
Chris Withers wrote:
> Jan-Wijbrand Kolman wrote:
>> Zope.sendmail explains in its README.txt that the developer using
>> zope.sendmail should himself take care of not sending emails (by setting
>> up a test layer for example, that would register a no-op IMailDelivery
>> utility).
>
> Why not just use testfixtures [1] and Mock [2] to replace the SMTP class
> in your testcase?
>
> from mock import Mock
> from testfixtures import replace
> @replace('smtplib.SMTP',Mock())
> def test_mystuff(self):
> ...
>
> That way you can check the right smtp calls are made, if you want to,
> and there's no chance of mail being sent?
>
My point is that I have to make sure the fixtures/mocking is done even
in indirect consumers of zope.sendmail.
What I mean is, if I run the tests of my application Foo, that uses an
application library MyLib where this MyLib library listens for events
that can trigger email being send, I need to *not forget* to use these
fixtures or mocks in the test setup of Foo. Even if the code of Foo does
not itself call zope.sendmail.
I had hoped there would be a way for either zope.sendmail, or perhaps
for MyLib, to make sure that no mail is ever send when running tests of Foo.
> This latter technique would probably work in a Layer too...
Right, that might work - I would need to define a test layer in MyLib
and not forget to use this base layer for the tests for Foo. It would be
slightly better, but it is still something I or a team member could
forget. Generally that would not be so much of a problem, however I
would hate to unintentionally send out mail...
Still I wonder about zope.testing.cleanup...
Thanks for the replies so far!
regards,
jw
___
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.sendmail and testing
Jan-Wijbrand Kolman wrote:
> Zope.sendmail explains in its README.txt that the developer using
> zope.sendmail should himself take care of not sending emails (by setting
> up a test layer for example, that would register a no-op IMailDelivery
> utility).
Why not just use testfixtures [1] and Mock [2] to replace the SMTP class
in your testcase?
from mock import Mock
from testfixtures import replace
@replace('smtplib.SMTP',Mock())
def test_mystuff(self):
...
That way you can check the right smtp calls are made, if you want to,
and there's no chance of mail being sent?
If you're doing a lot of tests, you might want to do:
from mock import Mock
from testfixtures import Replacer
class MyTests(TestCase):
def setUp(self):
self.r = Replacer
self.r.replace('smtplib.SMTP',Mock())
def tearDown(self):
self.r.restore()
This latter technique would probably work in a Layer too...
cheers,
Chris
[1] http://pypi.python.org/pypi/testfixtures
[2] http://pypi.python.org/pypi/mock
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
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.sendmail and testing
Hello, I think automagic things are evil. Later if you realize that you don't need them you have to fight to get rid of them. Tuesday, August 25, 2009, 4:19:30 PM, you wrote: JWK> Adam GROSZER wrote: >> Hello, >> >> I'd rather use a mailer stub for testing. >> Like the one in zope.sendmail.tests.test_mailer.py >> >> ... >> class SMTP(object): >> ... >> >> Something like this can be setup for individual tests with >> >> > name="mailer-name" >> provides="zope.sendmail.interfaces.IMailer" >> factory="your.own.mailerFactory" >> /> >> >> def mailerFactory(): >> mailer = SMTPMailer() >> mailer.smtp = SMTP >> return mailer JWK> Right, I see. However, what I meant to ask is if there is a way to have JWK> the registration of such a stub to be more or less automagically done JWK> during test runs by the zope.sendmail package instead of having to think JWK> about this over and over again in the packages directly or indirectly JWK> depending on it. JWK> I *thought* to see a way of getting rid of global data in JWK> zope.testing.cleanup, and I wonder if we could think of a way to set up JWK> global data in a similar manner JWK> regards, JWK> jw JWK> ___ JWK> Zope-Dev maillist - Zope-Dev@zope.org JWK> http://mail.zope.org/mailman/listinfo/zope-dev JWK> ** No cross posts or HTML encoding! ** JWK> (Related lists - JWK> http://mail.zope.org/mailman/listinfo/zope-announce JWK> http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: Success without honor is an unseasoned dish; it will satisfy your hunger, but it won't taste good. - Joe Paterno ___ 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.sendmail and testing
Adam GROSZER wrote: > Hello, > > I'd rather use a mailer stub for testing. > Like the one in zope.sendmail.tests.test_mailer.py > > ... > class SMTP(object): > ... > > Something like this can be setup for individual tests with > > name="mailer-name" > provides="zope.sendmail.interfaces.IMailer" > factory="your.own.mailerFactory" > /> > > def mailerFactory(): > mailer = SMTPMailer() > mailer.smtp = SMTP > return mailer Right, I see. However, what I meant to ask is if there is a way to have the registration of such a stub to be more or less automagically done during test runs by the zope.sendmail package instead of having to think about this over and over again in the packages directly or indirectly depending on it. I *thought* to see a way of getting rid of global data in zope.testing.cleanup, and I wonder if we could think of a way to set up global data in a similar manner regards, jw ___ 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.sendmail and testing
Hello, I'd rather use a mailer stub for testing. Like the one in zope.sendmail.tests.test_mailer.py ... class SMTP(object): ... Something like this can be setup for individual tests with def mailerFactory(): mailer = SMTPMailer() mailer.smtp = SMTP return mailer Tuesday, August 25, 2009, 2:48:57 PM, you wrote: JWK> Hello, JWK> We're using zope.sendmail to send mail from our applications. These JWK> applications are built on top of a more generic application library. It JWK> is this application library that depends on zope.sendmail. This JWK> application library listens for certain events and then can decide to JWK> send out an email. JWK> Obviously, when running the tests for the concrete application no mail JWK> is allowed to be actually sent. JWK> Zope.sendmail explains in its README.txt that the developer using JWK> zope.sendmail should himself take care of not sending emails (by setting JWK> up a test layer for example, that would register a no-op IMailDelivery JWK> utility). JWK> I had hoped that somehow zope.sendmail would automagically "detect" it JWK> is used during test runs and then would not send out any mails. JWK> I dug around in zope.testing and found the cleanup module that seems to JWK> provide (if I understand correctly) a global registry of things to JWK> cleanup after tests. I wonder if this could be extended to also be able JWK> to register routines for globally setting up stuff - in this case it JWK> could stub the mail delivery so that never ever any mail is actually JWK> send out when running tests. JWK> Questions: JWK> 1) how do others make sure that applications that directly or indirectly JWK> trigger sending mails do not actually send during testing? JWK> 2) am I on the right track thinking a "set up" equivalent of JWK> zope.testing.cleanup could be useful for these cases? JWK> kind regards, JWK> jw JWK> -- JWK> Jan-Wijbrand Kolman JWK> ___ JWK> Zope-Dev maillist - Zope-Dev@zope.org JWK> http://mail.zope.org/mailman/listinfo/zope-dev JWK> ** No cross posts or HTML encoding! ** JWK> (Related lists - JWK> http://mail.zope.org/mailman/listinfo/zope-announce JWK> http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com -- Quote of the day: To be upset over what you don't have is to waste what you do have. - Ken S. Keyes ___ 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.sendmail and testing
Hello, We're using zope.sendmail to send mail from our applications. These applications are built on top of a more generic application library. It is this application library that depends on zope.sendmail. This application library listens for certain events and then can decide to send out an email. Obviously, when running the tests for the concrete application no mail is allowed to be actually sent. Zope.sendmail explains in its README.txt that the developer using zope.sendmail should himself take care of not sending emails (by setting up a test layer for example, that would register a no-op IMailDelivery utility). I had hoped that somehow zope.sendmail would automagically "detect" it is used during test runs and then would not send out any mails. I dug around in zope.testing and found the cleanup module that seems to provide (if I understand correctly) a global registry of things to cleanup after tests. I wonder if this could be extended to also be able to register routines for globally setting up stuff - in this case it could stub the mail delivery so that never ever any mail is actually send out when running tests. Questions: 1) how do others make sure that applications that directly or indirectly trigger sending mails do not actually send during testing? 2) am I on the right track thinking a "set up" equivalent of zope.testing.cleanup could be useful for these cases? kind regards, jw -- Jan-Wijbrand Kolman ___ 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: zope.app.publisher refactoring
Hi Michael > Betreff: Re: AW: [Zope-dev] Proposal: zope.app.publisher refactoring > > Am 24.08.2009 um 22:55 schrieb Roger Ineichen: > [...] > > Everything which has to do with login has nothing to do in > > z3c.layer.pagelet. > > z3c.layer.pagelet should only offer a working setup for > pagelet based > > traversal stuff and error handling. > > Until we find a better place for it I'd like to keep it there > as it is a basic implementation (ported from > zope.app.security) of login/logout using pagelets/viewlets. > It is the pagelet version of login/logout as the other parts > are the pagelet version of error handling and traversal. I was looking another time at the z3c.layer.pagelet package. I agree that the added authentication support is usefull and was missing in the first releases. The loginForm.html pagelet should stay there. But we should move the viewlets to another package since this is optional and another concept which is not really needed by pagelets. e.g. z3c.authviewlet or so. Another reason for moving this viewlets is that this login/ logout viewlets are usfull too without using pagelets. Regards Roger Ineichen > Yours sincerely, > -- > Michael Howitz · m...@gocept.com · software developer gocept > gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · > germany http://gocept.com · tel +49 345 1229889 8 · fax +49 > 345 1229889 1 Zope and Plone consulting and development > > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Mon Aug 24 12:00:00 2009 UTC to Tue Aug 25 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Mon Aug 24 20:43:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012376.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon Aug 24 20:45:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012377.html Subject: OK : Zope-2.12 Python-2.4.6 : Linux From: Zope Tests Date: Mon Aug 24 20:47:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012378.html Subject: OK : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Mon Aug 24 20:49:52 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012379.html Subject: OK : Zope-2.12-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon Aug 24 20:51:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012380.html Subject: OK : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Aug 24 20:53:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012381.html Subject: OK : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Mon Aug 24 20:55:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012382.html Subject: OK : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Mon Aug 24 20:57:53 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-August/012383.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher 3.5 branch has code/behavior not a part of subsequent releases
Hi Gary > Betreff: Re: AW: [Zope-dev] zope.publisher 3.5 branch has > code/behavior not a part of subsequent releases > > > On Aug 24, 2009, at 6:02 PM, Roger Ineichen wrote: > > > Hi Tres > > > >> Betreff: Re: [Zope-dev] zope.publisher 3.5 branch has > code/behavior > >> not a part of subsequent releases > > > > [...] > > > >>> If I were not already behind, I would investigate to > understand the > >>> Python 2.6 problem better and see what other frameworks are doing > >>> here. I understand from conversations with other > engineers that at > >>> least some Django developers are accustomed to always > >> having access to > >>> the query string on the request object, whether the method > >> were get or > >>> post or whatever else. > >> > >> It is *essential* for correct operation that QUERY_STRING values > >> *not* be admixed with POSTed form values. I don't really > care how we > >> resolve your issue, as long as we do not end up in a case > where the > >> values in the query string get mingled into the form data: for > >> instance, we could hand a QUERY_STRING-free copy of the > environment > >> to the cgi.FieldStorage machinery. > > > > As far as I understand, you are saying that it is essential that > > posted data and a query string should be separated for > processing in > > python libraries e.g. FieldStorage or so. > > > > But this doesn't mean both values could not end in the request.form > > dict right? > > right, that's what he wants, and that's the pre-Py 2.6 behavior. > > > > >> Whatever gets done needs to leave the existing test in place:: > >> > >> self.assertEqual(dict(request.form), dict(x='1', y='2')) > >> > >> for a request whose QUERY_STRING was 'a=5&b:int=6', but > which posted > >> the 'x' and 'y' values. > > > > Was this supported before your changes? Is this a new feature you > > decided to add? What's the reason for this? Can you point > me to more > > infos? > > The constraint is an old behavior. > > The solution in 3.5.8 and 3.5.9 is a pretty big behavior > change if you are paying attention to the query string during POSTs. Ah, this sounds good. We often use query string urls for simulate a post request e.g. foo.html?form.action.remove=1&id=123 which forces to process the button action in z3c.form within a value 123 for the id field etc. I was afraid that this isn't working anymore if such query values will not longer work as request.form key/values But as far as I understand it's only a problem with POST and query strings and does not affect the above usecase. > Maybe http://bugs.python.org/issue1817 gives you the > information you want? Thanks a lot Roger Ineichen > Gary > > ___ 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 2.12: mkzopeinstance, runzope and zopectl - a small proposal
Hi Chris! Chris Withers wrote: > yuppie wrote: >> Currently buildout is just used to set up the software. > > Wrong. The buildout I posted, which uses no fancy recipes, sets up an > instance. The egg cache, as such, is "the software"... You ripped my sentence out of context. We were talking about Zope 2.12. And Zope 2.12 currently doesn't use buildout for setting up instances. Of course buildout in general is used in many ways and often for setting up instances. >> is used to set up instances. And while I see that using buildout for >> setting up everything in one step has some advantages, it's not the best >> pattern for all use cases. > > So tell us where it's not best rather than just asserting that such a > use case exists ;-) > >> mkzopeinstance helps to draw a line between software and data. > > No it doesn't. Plenty of software can live in an instance. > IMNSHO, buildout does a *better* job of drawing a line between software > and data... > >> that's important for distributors who want to distribute generic >> software, not user specific instance setups. > > Distributors just want a tarball or similar, let them use > zc.sourcerelease and have a slightly different buildout.cfg, or even > default.cfg, which uses that tarball as the source of eggs rather than > PyPI... > >> And sometimes it is useful >> to link an existing instance to a new buildout by updating some paths in >> instance/bin. > > I don't understand this. Please explain more... > >> Or to create several instances based on one buildout. > > Why? I guess the scenario you have in mind is a lightweight buildout that just contains some .cfg files describing the instance. There is nothing wrong about using buildout that way, but maybe it's wrong to make it the only supported way. The scenario I have in mind is a buildout that contains several development eggs. In that case it is expensive to update and rebuild a buildout. And you might have local changes in that buildout. These buildouts are more 'software' than 'instance'. Maybe with that scenario my assertions make more sense to you? >>> Cool. If only the zope2 egg could expose these now, it would make the >>> buildout.cfg simpler... just the matter of passing in the config. I >>> wonder if anyone can think of a nicer way of doing that? >> runzope and zopectl are defined as entry points: >> http://svn.zope.org/Zope/tags/2.12.0b4/setup.py?rev=102515&view=auto >> >> Or did you mean something else? > > I meant I nicer way of passing in the location of zope.conf... If you create the instance in the same step your solution doesn't look that bad. And if you use mkzopeinstance the command line option seems to be the right way to specify zope.conf. we can make it unnecessary to specify the interpreter. >>> When runzope and zopectl are built by buildout, this is already the >>> case... One python is used for both... >> No. Currently you also need 'zopepy' (or 'py' in your case). > > They're all the same python... Exactly. But if we always use the same Python, why do we have to specify it in several places? 4.) How do you create zopeservice.py for Windows? >>> What's Windows? Seriously though, I haven't needed to run Zope 2.12 on >>> Windows, so I don't know... >> But we have to support Windows. And I was able to get zopeservice.py >> running with mkzopeinstance. *If* we decide to use buildout the way you >> propose, someone has to figure out how to create zopeservice.py without >> mkzopeinstance. > > Sure, I can't imagine it's a particularly hard problem, it's just not > one the I'm interested in solving... That makes two of us. If nobody wants to do the work, your proposal is moot. Cheers, Yuppie ___ 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] Product configuration in zope.app.wsgi
On 2009-08-22, Uli Fouquet wrote: > > As it turned out product configurations are not set with > zope.app.wsgi (contrary, for instance, to zope.app.server). [...snip...] > Is there a special reason why that was not included in > zope.app.wsgi? My question exactly. And this raises another question: if it wasn't included, is that because there is a better way of handling configuration? My goal is to have settings in buildout, outside the actual code that uses it. So I want to use buildout for setting mail hosts and standard email recipients, stuff like that. Using a template recipe to generate a file somewhere? Stuff it into the ini file that is used by paste? More ideas? Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets" ___ 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 )
