From plone at hannosch.info Thu May 1 04:11:54 2008 From: plone at hannosch.info (Hanno Schlichting) Date: Thu May 1 04:12:06 2008 Subject: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: <004f01c8ab1f$2e167a20$8124fea9@mobile04> References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: <48197B4A.9090105@hannosch.info> Hi. Roger Ineichen wrote: > I added a new package for extract i18n locales > and I have some questions. > > Is it posible to split the zope.app.locales > package into a package which offers the > interfaces and classes e.g. PotMaker, > the generic extract.py file and another one > which provides the translation for zope.app? +1, right now I copied over the extract.py and interfaces.py to my i18ndude package, to avoid the zope.app dependency. The remaining dependencies on zope.i18n/messageid and zope.tal are perfectly reasonable IMO. I also had to make some adjustment where the code wheren't flexible enough, which I would like to merge back into the main line or the new package. I'm not good with names, but something like zope.i18nextract would work for me. Hanno From cz at gocept.com Thu May 1 05:27:07 2008 From: cz at gocept.com (Christian Zagrodnick) Date: Thu May 1 05:27:25 2008 Subject: [Zope-dev] Re: New i18n locale extraction concept References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: On 2008-05-01 02:06:17 +0200, "Roger Ineichen" said: > > > What does this mean? > The locale extraction is now a part of a recipe > and not a part of a package itself. > > My goal is to remove the dependencies in the > z3c.recipe.i18n, because right now it uses the > base implementation in zope.app.locales which makes > it depend on the hole zope namepsace. Because of > the overall zope.* dependenc in zope.app.locale. Actually, there is lovely.receipe:i18n which provides i18n extraction. Does z3c.recipe.i18n something else or why is there yet another i18n recipe? > The best option whould be to split zope.app.locales > into usefull packages. The not so good optipon whould > be to copy over the relevant classes and scripts to > the recipe and skip the dependency to zope.app.locale. > > I also started to use the recipe in z3c.locales > and zam.locales. Take a look at this package for > a real usecase. > > What do you think? Should we switch the locale extraction > to that concept for the zope.* packages too or not? Exctaction should be in a recipe, of course. But I'm also advocating for having the translations in the package and having one domain per package. ` -- Christian Zagrodnick gocept gmbh & co. kg ? forsterstrasse 29 ? 06112 halle/saale www.gocept.com ? fon. +49 345 12298894 ? fax. +49 345 12298891 From lgs at sicem.biz Thu May 1 05:35:09 2008 From: lgs at sicem.biz (Lorenzo Gil =?ISO-8859-1?Q?S=E1nchez?=) Date: Thu May 1 05:33:54 2008 Subject: [Zope-dev] call for comments for bug 159232 Message-ID: <1209634509.2902.10.camel@yog-sothoth.lorenzogil.com> Hi everybody, I'd like to know your opinion about bug 159232: https://bugs.launchpad.net/zope3/+bug/159232 It's about a IMHO wrong test in ItemDisplayWidget of the zope.app.form package. I've made a patch (the second one in that bug) with a test that exercise the bug and a fix for it but I'm not sure about the correctness of it and that's why I ask you for review. Here is the problem: - When the values of a vocabulary are containers and they are *empty* the __call__ method of ItemDisplayWidget will return an empty string for them, instead of its matching token. There are two possible solutions: A) Change the test inside the __call__ method so when checking the result of self._getFormValue() it explicitily checks for the empty string B) Do the conversion from the vocabulary value to a form value in a custom _getFormValue method in the ItemDisplayWidget class What do you guys think? best regards, Lorenzo From zope-tests at epy.co.at Thu May 1 07:00:05 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Thu May 1 07:00:07 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805011100.m41B05sF007516@shnoll.test.at> Summary of messages to the zope-tests list. Period Wed Apr 30 11:00:00 2008 UTC to Thu May 1 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed Apr 30 20:53:19 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009485.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 30 20:54:50 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009486.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 30 20:56:20 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009487.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 30 20:57:51 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009488.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed Apr 30 20:59:21 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009489.html From chris at simplistix.co.uk Thu May 1 07:17:11 2008 From: chris at simplistix.co.uk (Chris Withers) Date: Thu May 1 07:17:00 2008 Subject: [Zope-dev] Zope2 monitoring In-Reply-To: References: <20080430101653.GA26060@wiggy.net> <20080430104129.GF22653@mindy> Message-ID: <4819A6B7.4080500@simplistix.co.uk> Jens Vagelpohl wrote: >> If you're missing any probes/values, just tell me. > > Is it possible to determine process size/memory consumption? I know Andrew has done this for Cacti, I'd imagine these would port to Nagios... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk From ccomb at free.fr Thu May 1 08:25:26 2008 From: ccomb at free.fr (Christophe Combelles) Date: Thu May 1 08:25:18 2008 Subject: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: <4819B6B6.8070903@free.fr> Christian Zagrodnick a ?crit : > On 2008-05-01 02:06:17 +0200, "Roger Ineichen" said: >> >> >> What does this mean? >> The locale extraction is now a part of a recipe >> and not a part of a package itself. >> >> My goal is to remove the dependencies in the >> z3c.recipe.i18n, because right now it uses the >> base implementation in zope.app.locales which makes >> it depend on the hole zope namepsace. Because of >> the overall zope.* dependenc in zope.app.locale. > > Actually, there is lovely.receipe:i18n which provides i18n extraction. > Does z3c.recipe.i18n something else or why is there yet another i18n > recipe? > > >> The best option whould be to split zope.app.locales >> into usefull packages. The not so good optipon whould >> be to copy over the relevant classes and scripts to >> the recipe and skip the dependency to zope.app.locale. >> >> I also started to use the recipe in z3c.locales >> and zam.locales. Take a look at this package for >> a real usecase. >> >> What do you think? Should we switch the locale extraction >> to that concept for the zope.* packages too or not? > > Exctaction should be in a recipe, of course. But I'm also advocating for > having the translations in the package and having one domain per package. ` One drawback of this, is that it will be a pain for translators to gather and update translations, unless a tool is provided. Currently with only one file, there is already few languages. It's much more efficient for translators to work on one single big file than a lot of small ones. It will also prevent from using one same translation at different places, and identical messages will have to be translated several times, with the risk of not being consistent across packages. Unless everything is done by one person, using a translation memory. It seems obvious and logical to split the translation domains, but we need to provide a tool such as http://translationproject.org/extra/matrix.html that will allow - the package developer to submit a new POT file (by mail, upload, or anything) - translators to quickly see what need to be done and submit updated POs Ideally, the recipe i18n tool should be able to extract, merge, and give stats, just like in the monolithic zope release. Christophe > From dieter at handshake.de Thu May 1 13:45:23 2008 From: dieter at handshake.de (Dieter Maurer) Date: Thu May 1 13:45:45 2008 Subject: [Zope-dev] Zope2 monitoring In-Reply-To: <20080430101653.GA26060@wiggy.net> References: <20080430101653.GA26060@wiggy.net> Message-ID: <18458.435.331201.46807@gargle.gargle.HOWL> Wichert Akkerman wrote at 2008-4-30 12:16 +0200: > ... >I figured the medua monitorserver would be a good start, but judging >by the facts that it can only deal with clear-text passwords while the >rest of Zope uses hashed passwords and anything unexpected, such as >using command that produces a lot of output such as locals(), breaks >the whole session makes me suspect that nobody is using that. I use it occationally -- in order to analyse some difficult, non deterministically occuring problems. Doing so, I can add another misfeature: it swallows exceptions. I.e. executing something which raises an exception causes the interpreter to show its prompt without showing the exception or any other output. -- Dieter From dev at projekt01.ch Thu May 1 17:23:00 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Thu May 1 17:21:54 2008 Subject: AW: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: <014d01c8abd1$89194b70$0409a8c0@mobile04> Hi Christian > Betreff: [Zope-dev] Re: New i18n locale extraction concept [...] > > My goal is to remove the dependencies in the > z3c.recipe.i18n, because > > right now it uses the base implementation in zope.app.locales which > > makes it depend on the hole zope namepsace. Because of the overall > > zope.* dependenc in zope.app.locale. > > Actually, there is lovely.receipe:i18n which provides i18n > extraction. > Does z3c.recipe.i18n something else or why is there yet > another i18n recipe? Yes, I was using this recipe but it only works if the locales is a part of a package. It's not possible to extract translations from different packages into a own locales package. Note: the -d option use a path in the original i8nextract.py my new version uses egg or develop externals package as -d option. And allows to extract from different packages into a single *.locales package. > > The best option whould be to split zope.app.locales > > into usefull packages. The not so good optipon whould > > be to copy over the relevant classes and scripts to > > the recipe and skip the dependency to zope.app.locale. > > > > I also started to use the recipe in z3c.locales > > and zam.locales. Take a look at this package for > > a real usecase. > > > > What do you think? Should we switch the locale extraction > > to that concept for the zope.* packages too or not? > > Exctaction should be in a recipe, of course. But I'm also advocating > for having the translations in the package and having one domain per > package. ` Sometimes yes, soemtimes no. I think a own domain for pckages lie z3c.form is Ok. But I think we also need a shared domain for packages whihc only need to translate one, tow or a small amount of message ids. The benefit of a shared domain is the following: If someone speaking polnish or some other langauge then english and uses one or two packages he is probably willing to translate this packages. If we use a shared domain including the translation for a larger setup of packages, he is probably willing to translate all of them because he allready started the setup and beginns to translate. Regards Roger Ineichen > -- > Christian Zagrodnick > > gocept gmbh & co. kg . forsterstrasse 29 . 06112 halle/saale > www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891 From dev at projekt01.ch Thu May 1 17:29:22 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Thu May 1 17:28:15 2008 Subject: AW: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: <48197B4A.9090105@hannosch.info> References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <48197B4A.9090105@hannosch.info> Message-ID: <014e01c8abd2$6cc9de70$0409a8c0@mobile04> Hi Hanno > Betreff: [Zope-dev] Re: New i18n locale extraction concept > > Hi. > > Roger Ineichen wrote: > > I added a new package for extract i18n locales and I have some > > questions. > > > > Is it posible to split the zope.app.locales package into a package > > which offers the interfaces and classes e.g. PotMaker, the generic > > extract.py file and another one which provides the translation for > > zope.app? > > +1, right now I copied over the extract.py and interfaces.py to my > i18ndude package, to avoid the zope.app dependency. The > remaining dependencies on zope.i18n/messageid and zope.tal > are perfectly reasonable IMO. Yes > I also had to make some adjustment where the code wheren't > flexible enough, which I would like to merge back into the > main line or the new package. The main changes in the new concept is, that it uses egg or develop externals as -d option and theoriginal package uses path for the -d option. I think both concept could stay intact. The recipe could be used for extract locales for egg based packages and the original could be used for locales which are a part of the package itself. This whould avoid confusing others > I'm not good with names, but something like zope.i18nextract > would work for me. +1, that's fine for me > Hanno > > _______________________________________________ > 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 ) > From dev at projekt01.ch Thu May 1 17:38:20 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Thu May 1 17:37:15 2008 Subject: AW: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: <4819B6B6.8070903@free.fr> References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <4819B6B6.8070903@free.fr> Message-ID: <014f01c8abd3$addcb170$0409a8c0@mobile04> Hi Christophe > Betreff: Re: [Zope-dev] Re: New i18n locale extraction concept [....] > >> The best option whould be to split zope.app.locales into usefull > >> packages. The not so good optipon whould be to copy over > the relevant > >> classes and scripts to the recipe and skip the dependency to > >> zope.app.locale. > >> > >> I also started to use the recipe in z3c.locales and > zam.locales. Take > >> a look at this package for a real usecase. > >> > >> What do you think? Should we switch the locale extraction to that > >> concept for the zope.* packages too or not? > > > > Exctaction should be in a recipe, of course. But I'm also > advocating > > for having the translations in the package and having one > domain per > > package. ` > > One drawback of this, is that it will be a pain for > translators to gather and update translations, unless a tool > is provided. Currently with only one file, there is already > few languages. It's much more efficient for translators to > work on one single big file than a lot of small ones. +1, that's the main reason why I preferre shared domains in packages. Sometimes I only have one or two message ids which I think should stay in a shared domain.pot file rather then add a new domainn for them. Of corse a large amount of message ids in a z3c.* package can still provide a own domain. That's allways a valid option. My main point of view is the translator which have to speak a language. In his point of view it's simpler to have a single file instead of handling all the different packages he probaly doesn't even use. > It will also prevent from using one same translation at > different places, and identical messages will have to be > translated several times, with the risk of not being > consistent across packages. Unless everything is done by one > person, using a translation memory. +1, very good ideas! > It seems obvious and logical to split the translation > domains, but we need to provide a tool such as > http://translationproject.org/extra/matrix.html > that will allow > - the package developer to submit a new POT file (by mail, > upload, or anything) > - translators to quickly see what need to be done and submit > updated POs I agree, a tool whould be great. But the first we need to offer i18n extract script which can handle our new egg based buildout process. z3c.recipe.i18n is the only one which could handle this right now. > Ideally, the recipe i18n tool should be able to extract, > merge, and give stats, just like in the monolithic zope release. Yes, z3c.recipe.i18n does this right now. The -d option uses one or more egg or develop externals as argument instead of one single path. > Christophe > > > > > _______________________________________________ > 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 ) > From zope-tests at epy.co.at Fri May 2 07:00:05 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Fri May 2 07:00:06 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805021100.m42B0502001649@shnoll.test.at> Summary of messages to the zope-tests list. Period Thu May 1 11:00:00 2008 UTC to Fri May 2 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu May 1 20:56:52 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009490.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu May 1 20:58:22 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009491.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu May 1 20:59:53 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009492.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu May 1 21:01:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009493.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu May 1 21:02:53 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009494.html From jim at zope.com Fri May 2 15:09:48 2008 From: jim at zope.com (Jim Fulton) Date: Fri May 2 15:09:49 2008 Subject: [Zope-dev] New key upload program Message-ID: As most of you probably know, the machine that is known by many names, including mail.zope.org, svn.zope.org, cvs.zope.org, and download.zope.org, died Tuesday morning. Thanks to the heroic efforts of ZC operations staff, all of the services of the old machine were restored onto a new faster machine with a modern operating system. This was done by the end of Tuesday. One service that didn't make it was the old key-upload application. It used PHP libraries that we didn't want to move to the new box. Also, this program was pretty lame because it used a text area rather than a file upload to input keys. This led to lots of key mangling. I've replaced this application with a micro-Zope application. (This would have been a Bobo application if Bobo still lived. Bobo shall rise again!) The new application is available at: https://cvs.zope.org/upload-key.html If you need to change your keys, that's what you should use. For people who might want to become contributors, I've tried to create comprehensive yet concise set of instructions: http://www.zope.org/DevHome/Subversion/ImpatientPeoplesGuideToRequestingCommitPrivileges Jim -- Jim Fulton Zope Corporation From benji at zope.com Fri May 2 15:35:00 2008 From: benji at zope.com (Benji York) Date: Fri May 2 15:41:27 2008 Subject: [Zope-dev] New key upload program In-Reply-To: References: Message-ID: On Fri, May 2, 2008 at 3:09 PM, Jim Fulton wrote: > https://cvs.zope.org/upload-key.html I get an SSL error when visiting that page: Secure Connection Failed cvs.zope.org uses an invalid security certificate. The certificate expired on 11/10/2005 11:39 AM. Not something I'd normally complain about, but being a key uploader... -- Benji York Senior Software Engineer Zope Corporation From jim at zope.com Fri May 2 15:41:36 2008 From: jim at zope.com (Jim Fulton) Date: Fri May 2 15:41:45 2008 Subject: [Zope-dev] New key upload program In-Reply-To: References: Message-ID: <3A774ACB-D4DE-44E3-949E-A1D90FFE9DCF@zope.com> On May 2, 2008, at 3:35 PM, Benji York wrote: > On Fri, May 2, 2008 at 3:09 PM, Jim Fulton wrote: > >> https://cvs.zope.org/upload-key.html > > I get an SSL error when visiting that page: > > Secure Connection Failed > > cvs.zope.org uses an invalid security certificate. > > The certificate expired on 11/10/2005 11:39 AM. > > Not something I'd normally complain about, but being a key uploader... Not my problem. :) You got this from the old program to. This thing probably doesn't really need to be https. I just followed what was there before. Jim -- Jim Fulton Zope Corporation From srichter at cosmos.phy.tufts.edu Fri May 2 17:23:33 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Fri May 2 17:23:47 2008 Subject: [Zope-dev] New key upload program In-Reply-To: References: Message-ID: <200805021423.33414.srichter@cosmos.phy.tufts.edu> On Friday 02 May 2008, Jim Fulton wrote: > As most of you probably know, the machine that is known by many names, ? > including mail.zope.org, svn.zope.org, cvs.zope.org, and ? > download.zope.org, died Tuesday morning. Thanks to the heroic efforts ? > of ZC operations staff, all of the services of the old machine were ? > restored onto a new faster machine with a modern operating system. ? > This was done by the end of Tuesday. Kudos to the people there! It was great to see the services come back that quickly. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From faassen at startifact.com Fri May 2 17:21:43 2008 From: faassen at startifact.com (Martijn Faassen) Date: Fri May 2 17:25:05 2008 Subject: [Zope-dev] Re: New key upload program In-Reply-To: References: Message-ID: Hi there, Thanks to the heroic ZC operations staff, and thank you Jim for this new key upload program and the impatient people's guide! Regards, Martijn From wichert at wiggy.net Fri May 2 17:26:41 2008 From: wichert at wiggy.net (Wichert Akkerman) Date: Fri May 2 17:26:43 2008 Subject: [Zope-dev] Zope2 monitoring In-Reply-To: <20080430104129.GF22653@mindy> References: <20080430101653.GA26060@wiggy.net> <20080430104129.GF22653@mindy> Message-ID: <20080502212641.GA26998@wiggy.net> Previously Christian Theune wrote: > On Wed, Apr 30, 2008 at 12:16:53PM +0200, Wichert Akkerman wrote: > > I'm trying to figure out what the current state of the art for > > monitoring Zope2 processes is. Ideally I'ld want the equivalent of > > zc.z3monitor. > > > > I figured the medua monitorserver would be a good start, but judging > > by the facts that it can only deal with clear-text passwords while the > > rest of Zope uses hashed passwords and anything unexpected, such as > > using command that produces a lot of output such as locals(), breaks > > the whole session makes me suspect that nobody is using that. > > > > What do other people use? Is there any interest in improving the medusa > > monitor server? > > I'm still using and maintaining ZNagios[1] which, by now, has direct support for > Munin and Nagios. > > If you're missing any probes/values, just tell me. Detection of the correct number of zserver threads. Wichert. -- Wichert Akkerman It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. From zope-tests at epy.co.at Sat May 3 07:00:05 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Sat May 3 07:00:07 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805031100.m43B05Im022645@shnoll.test.at> Summary of messages to the zope-tests list. Period Fri May 2 11:00:00 2008 UTC to Sat May 3 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Fri May 2 20:54:43 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009495.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Fri May 2 20:56:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009496.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Fri May 2 20:57:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009497.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Fri May 2 20:59:14 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009498.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Fri May 2 21:00:44 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009499.html From zope-tests at epy.co.at Sun May 4 07:00:06 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Sun May 4 07:00:07 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805041100.m44B06BZ023481@shnoll.test.at> Summary of messages to the zope-tests list. Period Sat May 3 11:00:00 2008 UTC to Sun May 4 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Sat May 3 20:53:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009500.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 3 20:55:06 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009501.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 3 20:56:36 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009502.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Sat May 3 20:58:06 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009503.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Sat May 3 20:59:36 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009504.html From ct at gocept.com Sun May 4 18:06:51 2008 From: ct at gocept.com (Christian Theune) Date: Sun May 4 18:06:55 2008 Subject: [Zope-dev] TestRunner refactoring Message-ID: <20080504220651.GB7120@mindy> Hi, I've spend some time in the last days refactoring the current zope.testing TestRunner [1]. I didn't make huge functional changes (it's called refactoring after all) and tried being careful about changes in the output. However, I integrated unit tests and functional tests into normal layers from the test runners perspective. This currently results in unit tests being executed at some time (not necessarily at the beginning) and the layer name to change from 'unit' to 'Running zope.testing.testrunner.layer.UnitTests tests'. I kept close to the existing tests and made the whole approach more formalized pluggable and hopefully easier to understand. If nobody objects I'll merge my changes tomorrow and continue improving on that basis. Christian [1] svn://svn.zope.org/repos/main/zope.testing/branches/ctheune-cleanup -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development From zope-tests at epy.co.at Mon May 5 07:00:04 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Mon May 5 07:00:06 2008 Subject: [Zope-dev] Zope Tests: Message-ID: <200805051100.m45B04GP026481@shnoll.test.at> Summary of messages to the zope-tests list. Period Sun May 4 11:00:00 2008 UTC to Mon May 5 11:00:00 2008 UTC. There were no messages. From agroszer at gmail.com Mon May 5 12:57:24 2008 From: agroszer at gmail.com (Adam GROSZER) Date: Mon May 5 12:57:23 2008 Subject: [Zope-dev] mysqldbda bloats zodb Message-ID: <1615357324.20080505185724@gmail.com> Hello, I'm digging again around rdb and friends. It seems now that mysqldbda bloats zodb in def _connection_factory(self): """Create a MySQLdb DBI connection based on the DSN""" ... self.__stringConverter = MySQLStringConverter(self.getEncoding()) return connection on almost every request of us. That causes plenty of conflict errors I guess. But strangely we end up with ConnectionStateError: Shouldn't load state for 0x24 when the connection is closed (0x24 is the MySQLdbAdapter instance) So, I would move the assignment of __stringConverter to setEncoding where it belongs. (Change it only when the encoding changes). This seems to solve the above errors. Any objections? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: The work will wait while you show the child the rainbow, but the rainbow won't wait while you do the work. - Patricia Clafford From l at lrowe.co.uk Mon May 5 21:26:58 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Mon May 5 21:27:16 2008 Subject: [Zope-dev] zope.sqlalchemy Message-ID: Following discussions with Kapil, Christian and Martin I've developed zope.sqlalchemy. The aim is to provide a common base for transaction integration. It does not attempt to define any particular way to handle database configuration as there is not yet consensus on the best way to handle it. I've uploaded it to zope svn and pypi. See http://pypi.python.org/pypi/zope.sqlalchemy Currently it depends on a development version of SQLAlchemy. I hope to make a release following the 0.4.6 release of SQLAlchemy. See pypi or the readme for details, but briefly usage is something like: >>> engine = create_engine('sqlite:///') >>> Session = scoped_session(sessionmaker( ... bind=engine, transactional=True, autoflush=True, ... extension=ZopeTransactionExtension())) >>> session = Session() >>> session.save(User(name='bob')) >>> transaction.commit() Any comments appreciated. Laurence From lists at zopyx.com Tue May 6 00:01:14 2008 From: lists at zopyx.com (Andreas Jung) Date: Tue May 6 00:01:34 2008 Subject: [Zope-dev] zope.sqlalchemy In-Reply-To: References: Message-ID: --On 6. Mai 2008 02:26:58 +0100 Laurence Rowe wrote: > Following discussions with Kapil, Christian and Martin I've developed > zope.sqlalchemy. The aim is to provide a common base for transaction > integration. It does not attempt to define any particular way to handle > database configuration as there is not yet consensus on the best way to > handle it. > > I've uploaded it to zope svn and pypi. See > http://pypi.python.org/pypi/zope.sqlalchemy > > Currently it depends on a development version of SQLAlchemy. I hope to > make a release following the 0.4.6 release of SQLAlchemy. > > See pypi or the readme for details, but briefly usage is something like: > > >>> engine = create_engine('sqlite:///') > >>> Session = scoped_session(sessionmaker( > ... bind=engine, transactional=True, autoflush=True, > ... extension=ZopeTransactionExtension())) > >>> session = Session() > >>> session.save(User(name='bob')) > >>> transaction.commit() > > Any comments appreciated. > Looks great (on the paper :-)). Trying to integrate it with z3c.sqlalchemy over the weekend. Thanks Laurence. Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080506/d0850b01/attachment.bin From zope-tests at epy.co.at Tue May 6 07:00:05 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Tue May 6 07:00:06 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805061100.m46B05B4032259@shnoll.test.at> Summary of messages to the zope-tests list. Period Mon May 5 11:00:00 2008 UTC to Tue May 6 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Mon May 5 20:56:21 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009505.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 20:57:51 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009506.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 20:59:22 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009507.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 21:00:52 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009508.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Mon May 5 21:02:23 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009509.html From faassen at startifact.com Tue May 6 07:08:41 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue May 6 07:08:54 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: Hey, Laurence Rowe wrote: > See pypi or the readme for details, but briefly usage is something like: > > >>> engine = create_engine('sqlite:///') > >>> Session = scoped_session(sessionmaker( > ... bind=engine, transactional=True, autoflush=True, > ... extension=ZopeTransactionExtension())) > >>> session = Session() > >>> session.save(User(name='bob')) > >>> transaction.commit() One thing I understood from Christian Theune is that with scoped sessions, explicit session.save() is not always necessary. Since I see it being used here, could you perhaps comment on this? This is great news, also for megrok.rdb, which we started to develop at the Grokkerdam sprint. Regards, Martijn From agroszer at gmail.com Tue May 6 07:10:11 2008 From: agroszer at gmail.com (Adam GROSZER) Date: Tue May 6 07:10:09 2008 Subject: [Zope-dev] mysqldbda bloats zodb In-Reply-To: <1615357324.20080505185724@gmail.com> References: <1615357324.20080505185724@gmail.com> Message-ID: <1945691993.20080506131011@gmail.com> Silence is consent. Fix is ready and tested. I'll go ahead and fix this. Monday, May 5, 2008, 6:57:24 PM, you wrote: AG> Hello, AG> I'm digging again around rdb and friends. AG> It seems now that mysqldbda bloats zodb in AG> def _connection_factory(self): AG> """Create a MySQLdb DBI connection based on the DSN""" AG> ... AG> self.__stringConverter = AG> MySQLStringConverter(self.getEncoding()) AG> return connection AG> on almost every request of us. That causes plenty of conflict errors I AG> guess. But strangely we end up with AG> ConnectionStateError: Shouldn't load state for 0x24 when the connection is closed AG> (0x24 is the MySQLdbAdapter instance) AG> So, I would move the assignment of __stringConverter to setEncoding AG> where it belongs. (Change it only when the encoding changes). AG> This seems to solve the above errors. AG> Any objections? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: A professor is one who talks in someone else's sleep. From faassen at startifact.com Tue May 6 07:13:10 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue May 6 07:15:02 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: Laurence Rowe wrote: > I've uploaded it to zope svn and pypi. See > http://pypi.python.org/pypi/zope.sqlalchemy Another comment: Could you please use proper release numbers instead of the 0.1dev-r86482 stuff? And follow the official release procedure, which doesn't seem to be actually published on the web outside of grok.zope.org: http://grok.zope.org/documentation/how-to/releasing-software I realize that the package is very young, but I'm saying this for a reason; while doing it quickly seems convenience we've had a lot of troubles in the past building on such quick & dirty releases. Regards, Martijn From brian at vanguardistas.net Tue May 6 08:15:20 2008 From: brian at vanguardistas.net (Brian Sutherland) Date: Tue May 6 08:15:23 2008 Subject: [Zope-dev] zope.sqlalchemy In-Reply-To: References: Message-ID: <20080506121520.GB698@brian-sutherlands-macbook.local> On Tue, May 06, 2008 at 02:26:58AM +0100, Laurence Rowe wrote: > Any comments appreciated. It looks very, very good. -- Brian Sutherland From regebro at gmail.com Tue May 6 08:54:29 2008 From: regebro at gmail.com (Lennart Regebro) Date: Tue May 6 08:54:30 2008 Subject: [Zope-dev] Somebody needs to talk at EuropPython. Message-ID: <319e029f0805060554r6327a1c6j902389289083d749@mail.gmail.com> So, we need talks at EuropPython about both Repoze and Grok. I can't go, but I want to make sure *somebody* does. :) Hands up: Who is talking about Grok, and who talks about Repoze? :) Other super-cool Zope technologies that should be talked about? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 From faassen at startifact.com Tue May 6 10:21:52 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue May 6 10:25:02 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: Martijn Faassen wrote: > Laurence Rowe wrote: >> I've uploaded it to zope svn and pypi. See >> http://pypi.python.org/pypi/zope.sqlalchemy And yet another setup.py comment: the 'url' section right now points to http://svn.zope.org/zope.sqlalchemy'. I'm not sure, but I thought we had a policy not to use our SVN as the homepage URL in setup.py. Comments from others please? Regards, Martijn P.S. sorry for all the criticisms, they're intended to be constructive. I'm very excited this project is going ahead. From chrism at plope.com Tue May 6 10:48:41 2008 From: chrism at plope.com (Chris McDonough) Date: Tue May 6 10:48:52 2008 Subject: [Zope-dev] Re: [Repoze-dev] Somebody needs to talk at EuropPython. In-Reply-To: <319e029f0805060554r6327a1c6j902389289083d749@mail.gmail.com> References: <319e029f0805060554r6327a1c6j902389289083d749@mail.gmail.com> Message-ID: <48206FC9.3020500@plope.com> I can't go either. If anyone wanted to give a talk, they'd be welcome to use my repoze.zope2 slides at http://plope.com/static/presentations/repoze-zope2-pycon-2008.pdf (I also have it in Keynote format as necessary). - C Lennart Regebro wrote: > So, we need talks at EuropPython about both Repoze and Grok. I can't > go, but I want to make sure *somebody* does. :) > Hands up: Who is talking about Grok, and who talks about Repoze? :) > > Other super-cool Zope technologies that should be talked about? > From l at lrowe.co.uk Tue May 6 12:14:40 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Tue May 6 12:14:54 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: Martijn Faassen wrote: > Hey, > > Laurence Rowe wrote: >> See pypi or the readme for details, but briefly usage is something like: >> >> >>> engine = create_engine('sqlite:///') >> >>> Session = scoped_session(sessionmaker( >> ... bind=engine, transactional=True, autoflush=True, >> ... extension=ZopeTransactionExtension())) >> >>> session = Session() >> >>> session.save(User(name='bob')) >> >>> transaction.commit() > > One thing I understood from Christian Theune is that with scoped > sessions, explicit session.save() is not always necessary. Since I see > it being used here, could you perhaps comment on this? Registering a mapper with Session.mapper would work with this extension, but I'm reluctant to recommend it for two reasons: I don't know how it works with the declarative plugin; and it necessarily limits mapped classes to a single Session and therefor a single engine. In a zope context I think it's quite likely that you could have the same classes mapped to different databases (i.e. two instances of a single application). > This is great news, also for megrok.rdb, which we started to develop at > the Grokkerdam sprint. I read somewhere on one of the blog planets that you had discussed container implementations. Any more information/code about this? I'm quite hopeful that Zope 2.12 will let us share much more code now that Acquisition is being tamed. Laurence From mike_mp at zzzcomputing.com Tue May 6 12:53:05 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Tue May 6 12:53:08 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> On May 6, 2008, at 12:14 PM, Laurence Rowe wrote: > Martijn Faassen wrote: >> One thing I understood from Christian Theune is that with scoped >> sessions, explicit session.save() is not always necessary. Since I >> see it being used here, could you perhaps comment on this? > > Registering a mapper with Session.mapper would work with this > extension, but I'm reluctant to recommend it for two reasons: I > don't know how it works with the declarative plugin; and it > necessarily limits mapped classes to a single Session and therefor a > single engine. In a zope context I think it's quite likely that you > could have the same classes mapped to different databases (i.e. two > instances of a single application). hi there - a little background on the "save_on_init" option of Session.mapper. This behavior has its roots way back in SQLAlchemy 0.1, when there was no Session or Query or anything like that, and objects, when instantiated, went directly to a thread-local registry automatically. When SQLA 0.2 came out, we introduced all the additional constructs like Session and such which are familiar today, but extensions were provided which, when enabled, would re-enable the 0.1 behavior of "everything threadlocal/automatic" in a similar way. Ultimately thats where Session.mapper comes from. Like all typing-savers, "save on init" by then was used by dozens of Pylons users who swore by it and would scream and yell at any hint of removing this already legacy feature. At the same time, new users who were using Pylons tutorials (and therefore save_on_init, without really knowing it) in conjunction with creating their own Session objects were baffled by error messages like "object X is already in session Y". By the time 0.4 came out, we had started automating Session a lot more, adding autoflush capability to it. This feature immediately had issues with save_on_init for this reason: class MyClass(object): def __init__(self): self.some_variable = session.query(Foobar).filter(xyz).one() Where above, the query(Foobar) would fire off autoflush, MyClass would be flushed, and then an IntegrityError would be raised since MyClass would be missing some necessary state. Changing "save_on_init" to fire off *after* __init__ was a possibility there but then other things could break. So I've already not liked save_on_init for a couple of years due to its inherent intrusiveness, and because SA historically does not like being in the business of providing framework features (though we have decided to stay in that arena to some degree with declarative and scoped_session). The "Session.mapper" feature is stressed a whole lot less in the 0.4 docs, and as I work on the 0.5 docs this week I'm feeling very much like I'm going to remove it from the main documentation altogether. We''re consolidating the "save/update/save_or_update" names into just "add()" and "add_all()", so explicitly adding items to a Session should be a more pleasant experience which I wouldn't want anyone to miss. The aspect of Session.mapper which is somewhat reduntant vs. declarative is that they both want to add an automatic __init__(**kwargs) method which assigns all given keyword values to the instance. They are not incompatible because Session.mapper only adds an __init__ if none is available already. The final feature of Session.mapper which is more reasonable is the "query" attribute. This feature allows you to say: MyClass.query as an equivalent for session.query(MyClass). For that specific attribute, instead of using Session.mapper, its functionality has been exported into its own descriptor-producing method, like so: class MyBaseClass(object): query = Session.query_property() So this is a way to get that one aspect without buying into the Session.mapper thing. From gotcha at bubblenet.be Tue May 6 13:02:46 2008 From: gotcha at bubblenet.be (Godefroid Chapelle) Date: Tue May 6 13:03:09 2008 Subject: [Zope-dev] Re: [Repoze-dev] Somebody needs to talk at EuropPython. In-Reply-To: <319e029f0805060554r6327a1c6j902389289083d749@mail.gmail.com> References: <319e029f0805060554r6327a1c6j902389289083d749@mail.gmail.com> Message-ID: <48208F36.9060007@bubblenet.be> Lennart Regebro wrote: > So, we need talks at EuropPython about both Repoze and Grok. I can't > go, but I want to make sure *somebody* does. :) > Hands up: Who is talking about Grok, and who talks about Repoze? :) > > Other super-cool Zope technologies that should be talked about? > I think Lennart is really hitting a nail here. We need to advertize about our great efforts. I wont be in EuroPython even if I would have spoken about it with pleasure. -- Godefroid Chapelle (aka __gotcha) http://bubblenet.be From faassen at startifact.com Tue May 6 17:18:57 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue May 6 17:19:09 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: Message-ID: Laurence Rowe wrote: [snip] >> This is great news, also for megrok.rdb, which we started to develop >> at the Grokkerdam sprint. > > I read somewhere on one of the blog planets that you had discussed > container implementations. Any more information/code about this? I'm > quite hopeful that Zope 2.12 will let us share much more code now that > Acquisition is being tamed. Our sketchy code is in grokapps/rdbexample. The 'megrok.rdb' is a package in there right now. It's all cobbled together in unpolished form for the time being. We just basically reuse the mapping implementation SQLAlchemy already offers and give it an IContainer interface. It's not done yet but it's a large part of the solution. I'm writing a report on the grokkerdam sprint, but it isn't out yet. Regards, Martijn From faassen at startifact.com Tue May 6 17:24:17 2008 From: faassen at startifact.com (Martijn Faassen) Date: Tue May 6 17:24:24 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> Message-ID: Hey Michael, Thanks for the input! Michael Bayer wrote: [snip] > So I've already not liked save_on_init for a couple of years due to its > inherent intrusiveness, and because SA historically does not like being > in the business of providing framework features (though we have decided > to stay in that arena to some degree with declarative and scoped_session). I'll try to summarize the discussion so I can find out whether I understand it. Basically you're saying you don't think save on instantiation is a good idea generally, and that we should be using session.save(). This is going to be changed to session.add() in the future. What would session.add_all() do? This ties into the mapper feature, which also offers other features. The one feature that will remain but in a new shape, without the mapper, is the ability to do MyClass.query. Is that a correct summary? Regards, Martijn From ct at gocept.com Tue May 6 17:55:01 2008 From: ct at gocept.com (Christian Theune) Date: Tue May 6 17:55:03 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> Message-ID: <20080506215501.GB15736@mindy> Hi, On Tue, May 06, 2008 at 12:53:05PM -0400, Michael Bayer wrote: > > On May 6, 2008, at 12:14 PM, Laurence Rowe wrote: > >> Martijn Faassen wrote: >>> One thing I understood from Christian Theune is that with scoped >>> sessions, explicit session.save() is not always necessary. Since I >>> see it being used here, could you perhaps comment on this? >> >> Registering a mapper with Session.mapper would work with this >> extension, but I'm reluctant to recommend it for two reasons: I don't >> know how it works with the declarative plugin; and it necessarily >> limits mapped classes to a single Session and therefor a single engine. >> In a zope context I think it's quite likely that you could have the >> same classes mapped to different databases (i.e. two instances of a >> single application). > > hi there - > > a little background on the "save_on_init" option of Session.mapper. > This behavior has its roots way back in SQLAlchemy 0.1, when there was > no Session or Query or anything like that, and objects, when > instantiated, went directly to a thread-local registry automatically. > When SQLA 0.2 came out, we introduced all the additional constructs like > Session and such which are familiar today, but extensions were provided > which, when enabled, would re-enable the 0.1 behavior of "everything > threadlocal/automatic" in a similar way. Ultimately thats where > Session.mapper comes from. That's interesting, thanks for the heads-up. For some reason I didn't hit that and was quite happy with save on init (I obviously only use one database at a time ...) but the reasons and concerns given tell me that our core transaction integration shouldn't force this onto people and we might not want to use it for grok at all. In fact at the sprint we discussed the similarities and differences of RDB versus ODB and found that the step of 'add an object to the db' is actually two functions (in one gesture) in the ODB: relate object B to object A and, therefore add it to the same database as object A is in. Whereas (due to the mapping of classes to tables) in RDB we only need to tell which database to go to. Those are similar but differen gestures and I'm not sure we had a definitive result when discussing this. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development From m.van.rees at zestsoftware.nl Tue May 6 18:24:09 2008 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Tue May 6 18:24:19 2008 Subject: [Zope-dev] Re: New i18n locale extraction concept References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: Christian Zagrodnick, on 2008-05-01: > On 2008-05-01 02:06:17 +0200, "Roger Ineichen" said: >> >> >> What does this mean? >> The locale extraction is now a part of a recipe >> and not a part of a package itself. >> >> My goal is to remove the dependencies in the >> z3c.recipe.i18n, because right now it uses the >> base implementation in zope.app.locales which makes >> it depend on the hole zope namepsace. Because of >> the overall zope.* dependenc in zope.app.locale. > > Actually, there is lovely.receipe:i18n which provides i18n extraction. > Does z3c.recipe.i18n something else or why is there yet another i18n > recipe? For me a downside of lovely.recipe:i18n is that it has too many dependencies: the whole of zope. When easy installing it in a virtual env, you end up with 44 MB of eggs. For comparison, easy installing i18ndude needs about 6 MB. See this (currently) small thread in grok-dev: http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742 -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] From mike_mp at zzzcomputing.com Tue May 6 19:13:53 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Tue May 6 19:13:54 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> Message-ID: On May 6, 2008, at 5:24 PM, Martijn Faassen wrote: > Hey Michael, > > Thanks for the input! > > Michael Bayer wrote: > [snip] >> So I've already not liked save_on_init for a couple of years due to >> its inherent intrusiveness, and because SA historically does not >> like being in the business of providing framework features (though >> we have decided to stay in that arena to some degree with >> declarative and scoped_session). > > I'll try to summarize the discussion so I can find out whether I > understand it. Basically you're saying you don't think save on > instantiation is a good idea generally, and that we should be using > session.save(). This is going to be changed to session.add() in the > future. What would session.add_all() do? session.add_all() is just: session.add_all([obj1, obj2, obj3, ...]) Also session.save()/update/save_or_update will remain throughout 0.5 at least. > This ties into the mapper feature, which also offers other features. > The one feature that will remain but in a new shape, without the > mapper, is the ability to do MyClass.query. > > > Is that a correct summary? Session.mapper and save_on_init has no plans of going away in 0.5, but I plan to de-emphasize it. The "query" descriptor function is also available in 0.4. - mike From novotny.radim at gmail.com Wed May 7 02:10:27 2008 From: novotny.radim at gmail.com (Radim Novotny) Date: Wed May 7 02:15:07 2008 Subject: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn -- Some packages may not be found! In-Reply-To: <008801c89fea$3545f540$0463a8c0@mobile04> References: <480623A5.6030702@eastlink.ca> <008801c89fea$3545f540$0463a8c0@mobile04> Message-ID: Roger Ineichen napsal(a): > Hi David > >> Betreff: [Zope-dev] Annoying: Download error: unknown url >> type: svn -- Some packages may not be found! >> >> Which package is emitting the Download error: unknown url >> type: svn -- Some packages may not be found! Its quite >> annoying and I have been seeing it crop up in a few builds. >> Anyone else seeing this. Many thanks. > > I see this too. Try the buildout debug option, probably this > will you give a better output. I have got the same error today. buildout -vvvv was not sufficient so I added print output to setuptools/package_index.py and discovered this message is caused by z3c.form: Getting required 'z3c.form' required by plone.z3cform 0.1b2. Reading http://pypi.python.org/simple/z3c.form/ Reading svn://svn.zope.org/repos/main/z3c.form Download error: unknown url type: svn -- Some packages may not be found! Reading http://svn.zope.org/z3c.form We have the best distribution that satisfies 'z3c.form'. Adding find link 'http://download.zope.org/distribution' from z3c.form 1.8.2 Picked: z3c.form = 1.8.2 -- Radim Novotny From m.van.rees at zestsoftware.nl Wed May 7 05:17:27 2008 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Wed May 7 05:17:44 2008 Subject: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn -- Some packages may not be found! References: <480623A5.6030702@eastlink.ca> <008801c89fea$3545f540$0463a8c0@mobile04> Message-ID: Radim Novotny, on 2008-05-07: > Roger Ineichen napsal(a): >> Hi David >> >>> Betreff: [Zope-dev] Annoying: Download error: unknown url >>> type: svn -- Some packages may not be found! >>> >>> Which package is emitting the Download error: unknown url >>> type: svn -- Some packages may not be found! Its quite >>> annoying and I have been seeing it crop up in a few builds. >>> Anyone else seeing this. Many thanks. >> >> I see this too. Try the buildout debug option, probably this >> will you give a better output. > > I have got the same error today. buildout -vvvv was not sufficient so I > added print output to setuptools/package_index.py and discovered this > message is caused by z3c.form: The same happens for lovely.recipe: http://pypi.python.org/simple/lovely.recipe What is considered to be good practice here? For example this is in the setup.py of grokproject: url='https://launchpad.net/grok', download_url='svn://svn.zope.org/repos/main/grokproject/trunk#egg=grokproject-dev', Looking at the simple cheese shop page: http://pypi.python.org/simple/grokproject I see that the home page url for all released versions is the launchpad url which is probably fine. But the download url is also the same for every release that I checked, namely the trunk#egg, which does not look like a good idea. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] From dev at projekt01.ch Wed May 7 06:45:59 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Wed May 7 06:44:55 2008 Subject: AW: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found! In-Reply-To: References: <480623A5.6030702@eastlink.ca><008801c89fea$3545f540$0463a8c0@mobile04> Message-ID: <007701c8b02f$8a600840$0409a8c0@mobile04> Hi > Betreff: [Zope-dev] Re: AW: Annoying: Download error: unknown > url type: svn-- Some packages may not be found! [...] > > I have got the same error today. buildout -vvvv was not > sufficient so > > I added print output to setuptools/package_index.py and discovered > > this message is caused by z3c.form: > > The same happens for lovely.recipe: > > http://pypi.python.org/simple/lovely.recipe I had no time to take a closer look at that. But I guess it's the lovely.recipe which forces to return the svn-- message. Regards Roger Ineichen > What is considered to be good practice here? For example > this is in the setup.py of grokproject: > > url='https://launchpad.net/grok', > > download_url='svn://svn.zope.org/repos/main/grokproject/trunk# > egg=grokproject-dev', > > Looking at the simple cheese shop page: > > http://pypi.python.org/simple/grokproject > > I see that the home page url for all released versions is the > launchpad url which is probably fine. But the download url > is also the same for every release that I checked, namely the > trunk#egg, which does not look like a good idea. > > -- > Maurits van Rees | http://maurits.vanrees.org/ > Work | http://zestsoftware.nl/ "This is your day, > don't let them take it away." [Barlow Girl] > > _______________________________________________ > 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 ) > From dev at projekt01.ch Wed May 7 06:51:30 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Wed May 7 06:50:24 2008 Subject: AW: [Zope-dev] Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> Message-ID: <007b01c8b030$4fdcac40$0409a8c0@mobile04> Hi Maurits > Betreff: [Zope-dev] Re: New i18n locale extraction concept > > Christian Zagrodnick, on 2008-05-01: > > On 2008-05-01 02:06:17 +0200, "Roger Ineichen" > said: > >> > >> > >> What does this mean? > >> The locale extraction is now a part of a recipe and not a > part of a > >> package itself. > >> > >> My goal is to remove the dependencies in the > z3c.recipe.i18n, because > >> right now it uses the base implementation in > zope.app.locales which > >> makes it depend on the hole zope namepsace. Because of the overall > >> zope.* dependenc in zope.app.locale. > > > > Actually, there is lovely.receipe:i18n which provides i18n > extraction. > > Does z3c.recipe.i18n something else or why is there yet > another i18n > > recipe? > > For me a downside of lovely.recipe:i18n is that it has too many > dependencies: the whole of zope. When easy installing it in > a virtual env, you end up with 44 MB of eggs. > > For comparison, easy installing i18ndude needs about 6 MB. Yes, that's what I was asking for. The zope.app.locales has dependencies to each i18n aware zope.* package because it offers transalation for this packages. And at the same time it offers the i18nextract.py script which could be used by other projects. This ends in having dependencies to all zope.* packages. We need to split the locale extraction concept and the concret zope.* package extraction part into two different packages. Then we can reuse the local extraction concept wihtout dependencies to the full zope.* package tree. Regards Roger Ineichen > See this (currently) small thread in grok-dev: > http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742 > > -- > Maurits van Rees | http://maurits.vanrees.org/ > Work | http://zestsoftware.nl/ "This is your day, > don't let them take it away." [Barlow Girl] > > _______________________________________________ > 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 ) > From zope-tests at epy.co.at Wed May 7 07:00:13 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Wed May 7 07:00:14 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805071100.m47B0DXB030917@shnoll.test.at> Summary of messages to the zope-tests list. Period Tue May 6 11:00:00 2008 UTC to Wed May 7 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Tue May 6 21:06:34 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009510.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:08:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009511.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:09:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009512.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:11:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009513.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Tue May 6 21:12:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009514.html From agroszer at gmail.com Wed May 7 07:09:42 2008 From: agroszer at gmail.com (Adam GROSZER) Date: Wed May 7 07:09:40 2008 Subject: AW: [Zope-dev] Re: AW: Annoying: Download error: unknown url type: svn-- Some packages may not be found! In-Reply-To: <007701c8b02f$8a600840$0409a8c0@mobile04> References: <480623A5.6030702@eastlink.ca><008801c89fea$3545f540$0463a8c0@mobile04> <007701c8b02f$8a600840$0409a8c0@mobile04> Message-ID: <501854800.20080507130942@gmail.com> Hello Roger, Might be, lovely.recipe's pypi page looks like: Author: Lovely Systems Home Page: svn://svn.zope.org/repos/main/lovely.recipe Keywords: buildout recipe filesystem i18n importchecker License: ZPL 2.1 Package Index Owner: batlogg I guess the Home Page makes it crazy. Wednesday, May 7, 2008, 12:45:59 PM, you wrote: RI> Hi >> Betreff: [Zope-dev] Re: AW: Annoying: Download error: unknown >> url type: svn-- Some packages may not be found! RI> [...] >> > I have got the same error today. buildout -vvvv was not >> sufficient so >> > I added print output to setuptools/package_index.py and discovered >> > this message is caused by z3c.form: >> >> The same happens for lovely.recipe: >> >> http://pypi.python.org/simple/lovely.recipe RI> I had no time to take a closer look at that. But I guess RI> it's the lovely.recipe which forces to return the RI> svn-- message. RI> Regards RI> Roger Ineichen >> What is considered to be good practice here? For example >> this is in the setup.py of grokproject: >> >> url='https://launchpad.net/grok', >> >> download_url='svn://svn.zope.org/repos/main/grokproject/trunk# >> egg=grokproject-dev', >> >> Looking at the simple cheese shop page: >> >> http://pypi.python.org/simple/grokproject >> >> I see that the home page url for all released versions is the >> launchpad url which is probably fine. But the download url >> is also the same for every release that I checked, namely the >> trunk#egg, which does not look like a good idea. >> >> -- >> Maurits van Rees | http://maurits.vanrees.org/ >> Work | http://zestsoftware.nl/ "This is your day, >> don't let them take it away." [Barlow Girl] >> >> _______________________________________________ >> 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 ) >> RI> _______________________________________________ RI> Zope-Dev maillist - Zope-Dev@zope.org RI> http://mail.zope.org/mailman/listinfo/zope-dev RI> ** No cross posts or HTML encoding! ** RI> (Related lists - RI> http://mail.zope.org/mailman/listinfo/zope-announce RI> http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: People in distress will sometimes prefer a problem that is familiar to a solution that is not. - Neil Postman From faassen at startifact.com Wed May 7 07:08:06 2008 From: faassen at startifact.com (Martijn Faassen) Date: Wed May 7 07:10:01 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: <20080506215501.GB15736@mindy> References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Hi there (especially Christian), I think we can work with explicits saves. In many cases the user won't have to worry about it anyway as the container object will do it for them (besides making the relation), or this 'query container' we spoke of will do it for them (but just the 'save' bit). One point is that the scoped session approach itself doesn't work very well for using multiple databases in the same app. We could consider passing the session along in the containers during object graph wakling (or traversal) so an app can easily traverse into multiple databases. I'm not sure whether we can make the ORM do this for us though; does it initialize the mapping with a session? Regards, Martijn From l at lrowe.co.uk Wed May 7 08:48:52 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 08:48:59 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Martijn Faassen wrote: > Hi there (especially Christian), > > I think we can work with explicits saves. In many cases the user won't > have to worry about it anyway as the container object will do it for > them (besides making the relation), or this 'query container' we spoke > of will do it for them (but just the 'save' bit). > > One point is that the scoped session approach itself doesn't work very > well for using multiple databases in the same app. We could consider > passing the session along in the containers during object graph wakling > (or traversal) so an app can easily traverse into multiple databases. > I'm not sure whether we can make the ORM do this for us though; does it > initialize the mapping with a session? Registering a ScopedSession as a utility seems a good approach. I'm experimenting with ways of registering engines as local utilities. Hopefully the combination will allow something along the lines of: >>> Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...)) >>> provideUtility(Session, IScopedSession, 'my-app') >>> engine = EngineUtility(url='sqlite:///') >>> provideUtility(engine, IConnectable, 'my-engine') # but normally a local utility registration The code would get a session through: >>> Session = getUtility(IScopedSession, 'my-app') >>> session = Session() Mappers are registered with the metadata, so nothing special need be done here. Laurence From mike_mp at zzzcomputing.com Wed May 7 09:33:05 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Wed May 7 09:33:07 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: On May 7, 2008, at 7:08 AM, Martijn Faassen wrote: > Hi there (especially Christian), > > I think we can work with explicits saves. In many cases the user > won't have to worry about it anyway as the container object will do > it for them (besides making the relation), or this 'query container' > we spoke of will do it for them (but just the 'save' bit). > > One point is that the scoped session approach itself doesn't work > very well for using multiple databases in the same app. We could > consider passing the session along in the containers during object > graph wakling (or traversal) so an app can easily traverse into > multiple databases. I'm not sure whether we can make the ORM do this > for us though; does it initialize the mapping with a session? > SQLAlchemy's Session does support multiple engine binds itself, which most easily can be associated with particular mapped classes (i.e. vertical partitioning), so that a single session (or a scoped_session) can read and write data to the appropriate tables transparently (although things like joins across multiple databases will raise errors). Theres a horizontally-partitioning version of Session as well which obviously has a lot more caveats. Using multiple sessions, one per DB is a valid approach as well. I'm not sure if Grok has other things going on when mulitple DBs are in use but SA's multi-bind capability is something to be aware of. From dev at projekt01.ch Wed May 7 10:16:48 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Wed May 7 10:15:47 2008 Subject: [Zope-dev] Heads up - package lost on pypi! Message-ID: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04> Hi all The z3c.configurator package is gone on PyPi. Does sombody know what's happen? And more important, how can we recover this? Regards Roger Ineichen _____________________________ END OF MESSAGE From faassen at startifact.com Wed May 7 10:15:52 2008 From: faassen at startifact.com (Martijn Faassen) Date: Wed May 7 10:16:07 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Hi there, Laurence Rowe wrote: [snip] > The code would get a session through: > > >>> Session = getUtility(IScopedSession, 'my-app') > >>> session = Session() The drawback is that this is more typing. You do a utility lookup and an instantiation as opposed to simply importing the scoped session when needed: from myapplication import session session.query(...) One topic we ran into during the megrok.kss discussion is doing multiple instances of the same application, each writing to a different database. You can't hardcode your database name in your application. I think sessions as local utilities would help us solve that problem, right? What would be nice if we could do the 'from myapp import session' pattern and have it use the local utility infrastructure underneath somehow... Possible? Regards, Martijn From mbaiju at zeomega.com Wed May 7 10:22:13 2008 From: mbaiju at zeomega.com (Baiju M) Date: Wed May 7 10:22:27 2008 Subject: [Zope-dev] Heads up - package lost on pypi! In-Reply-To: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04> References: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04> Message-ID: <4821BB15.7000207@zeomega.com> Roger Ineichen wrote: > Hi all > > The z3c.configurator package is gone on PyPi. > > Does sombody know what's happen? And more important, how can we > recover this? AFAIK, only owners can delete it. May be deleted by an owner by mistake. I am not sure whether we can recover it. Regards, Baiju M From faassen at startifact.com Wed May 7 10:38:29 2008 From: faassen at startifact.com (Martijn Faassen) Date: Wed May 7 10:38:36 2008 Subject: [Zope-dev] Re: Heads up - package lost on pypi! In-Reply-To: <4821BB15.7000207@zeomega.com> References: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04> <4821BB15.7000207@zeomega.com> Message-ID: Baiju M wrote: > Roger Ineichen wrote: >> Hi all >> >> The z3c.configurator package is gone on PyPi. >> >> Does sombody know what's happen? And more important, how can we >> recover this? > > AFAIK, only owners can delete it. > May be deleted by an owner by mistake. > I am not sure whether we can recover it. Are really sure it ever existed? Googling for: "http://pypi.python.org/pypi/z3c.configurator" didnt' return any obvious hits. Doesn't mean much, it might not have made it to the index. Note that there is a z3c.configurator upload here: http://download.zope.org/distribution/ Regards, Martijn From dev at projekt01.ch Wed May 7 11:04:51 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Wed May 7 11:03:48 2008 Subject: AW: [Zope-dev] Re: Heads up - package lost on pypi! In-Reply-To: References: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04><4821BB15.7000207@zeomega.com> Message-ID: <010101c8b053$b4a97e00$0409a8c0@mobile04> Hi > Betreff: [Zope-dev] Re: Heads up - package lost on pypi! > > Baiju M wrote: > > Roger Ineichen wrote: > >> Hi all > >> > >> The z3c.configurator package is gone on PyPi. > >> > >> Does sombody know what's happen? And more important, how can we > >> recover this? > > > > AFAIK, only owners can delete it. > > May be deleted by an owner by mistake. > > I am not sure whether we can recover it. > > Are really sure it ever existed? > > Googling for: > > "http://pypi.python.org/pypi/z3c.configurator" > > didnt' return any obvious hits. Doesn't mean much, it might > not have made it to the index. Note that there is a > z3c.configurator upload here: > > http://download.zope.org/distribution/ hehe, I guess you are right. Seems that the package never exist on pypi. bad, bad I just uploaded the released 1.1.1 tag version to pypi and will cleanup the setup and release a documented version later. Should I add someone as additional pypi Owner to that package? Regards Roger Ineichen _____________________________ END OF MESSAGE > 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 ) > From l at lrowe.co.uk Wed May 7 12:11:27 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 12:11:44 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Martijn Faassen wrote: > Hi there, > > Laurence Rowe wrote: > [snip] >> The code would get a session through: >> >> >>> Session = getUtility(IScopedSession, 'my-app') >> >>> session = Session() > > The drawback is that this is more typing. You do a utility lookup and an > instantiation as opposed to simply importing the scoped session when > needed: > > from myapplication import session > > session.query(...) > > One topic we ran into during the megrok.kss discussion is doing multiple > instances of the same application, each writing to a different database. > You can't hardcode your database name in your application. I think > sessions as local utilities would help us solve that problem, right? > > What would be nice if we could do the 'from myapp import session' > pattern and have it use the local utility infrastructure underneath > somehow... Possible? We'll have to stick with scoped sesssions because of threading, but the engine as local utility pattern should still work. #myapplication/__init__.py Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...)) engine = EngineUtility(url='sqlite:///') provideUtility(engine, IConnectable, 'my-engine') # but normally a local utility registration #myapplication/foo.py from myapplication import Session session = Session() One (perhaps the only) advantage I can see with looking up the scoped session as a utility is that it gives the integrator control over whether to use one or two phase commit, as this is set in the session configuration. Normally one would prefer one-phase commit as it is faster, but if an integrator arranged for two applications to be modified in a single transaction she would want to configure two-phase commit. Laurence From faassen at startifact.com Wed May 7 12:38:38 2008 From: faassen at startifact.com (Martijn Faassen) Date: Wed May 7 12:39:11 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Hey Laurence, Laurence Rowe wrote: [snip] > We'll have to stick with scoped sesssions because of threading, but the > engine as local utility pattern should still work. > > #myapplication/__init__.py > Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...)) > engine = EngineUtility(url='sqlite:///') > provideUtility(engine, IConnectable, 'my-engine') # but normally a local > utility registration > > #myapplication/foo.py > from myapplication import Session > session = Session() Here one still needs to instantiate the session each time you use it. Couldn't you simply do: #myapplication/__init__.py ... [what you had] session = Session() # myapplication/foo.py from myapplication import session or wouldn't that be possible? > One (perhaps the only) advantage I can see with looking up the scoped > session as a utility is that it gives the integrator control over > whether to use one or two phase commit, as this is set in the session > configuration. Normally one would prefer one-phase commit as it is > faster, but if an integrator arranged for two applications to be > modified in a single transaction she would want to configure two-phase > commit. How common would it be that the integrator would do this without the code itself needing to be changed for other reasons then too? A WSGI setup, perhaps? I imagine we could arrange something where we allow both. Provide the engine as local utility scenario, but let people register sessions as local utilities should they want to. Regards, Martijn From l at lrowe.co.uk Wed May 7 13:29:33 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 13:29:44 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Michael Bayer wrote: > > On May 7, 2008, at 7:08 AM, Martijn Faassen wrote: > >> Hi there (especially Christian), >> >> I think we can work with explicits saves. In many cases the user won't >> have to worry about it anyway as the container object will do it for >> them (besides making the relation), or this 'query container' we spoke >> of will do it for them (but just the 'save' bit). >> >> One point is that the scoped session approach itself doesn't work very >> well for using multiple databases in the same app. We could consider >> passing the session along in the containers during object graph >> wakling (or traversal) so an app can easily traverse into multiple >> databases. I'm not sure whether we can make the ORM do this for us >> though; does it initialize the mapping with a session? >> > > SQLAlchemy's Session does support multiple engine binds itself, which > most easily can be associated with particular mapped classes (i.e. > vertical partitioning), so that a single session (or a scoped_session) > can read and write data to the appropriate tables transparently > (although things like joins across multiple databases will raise > errors). Theres a horizontally-partitioning version of Session as well > which obviously has a lot more caveats. > > Using multiple sessions, one per DB is a valid approach as well. I'm > not sure if Grok has other things going on when mulitple DBs are in use > but SA's multi-bind capability is something to be aware of. I'm thinking more about having the same classes mapped to different databases at different points in the application. Imagine a departmental address book app. Intstances of the departmental address book are created for each department, each with a different databases: http://addressbook/sales -> postgres:///sales http://addressbook/engineering -> postgres:///engineering The way I imagine this working is to have a proxy engine object that looks up the real engine through a local utility. Each application would be a `site` and capable of local utility registrations. /sales would have Engine('postgres:///sales') registered and /engineering Engine('postgres:///engineering'). Only a single ScopedSession would be required. This would be bound to proxy that performs the utility lookup. So when in the /sales context the proxy would point to the sales engine and when in the /engineering context to the engineering engine. The limitation of this approach is that it would not be possible to mix objects from /sales and objects from /engineering into the same transaction. So really we need a session per application instance. Perhaps this can be achieved through a custom scoping function: def scopefunc(): return thread.get_ident(), id(zope.component.getSiteManager()) Laurence From mborch at gmail.com Wed May 7 13:34:30 2008 From: mborch at gmail.com (Malthe Borch) Date: Wed May 7 13:34:43 2008 Subject: [Zope-dev] Re: Buildout Builder: Call for Ideas. In-Reply-To: <86C45136-A19E-4E4F-849E-CB1B2487A549@gmail.com> References: <86C45136-A19E-4E4F-849E-CB1B2487A549@gmail.com> Message-ID: <4821E826.8020903@gmail.com> Kenneth Miller wrote: > Any and all feedback is appreciated and I will carefully consider > every idea. For your application: "A major drawback is that the underlying architecture relies on setup file based configuration." Does it, and is it? \malthe From l at lrowe.co.uk Wed May 7 13:54:49 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 13:54:56 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Martijn Faassen wrote: > Hey Laurence, > > Laurence Rowe wrote: > [snip] >> We'll have to stick with scoped sesssions because of threading, but >> the engine as local utility pattern should still work. >> >> #myapplication/__init__.py >> Session = scoped_session(sessionmaker(bind=LookupEngine('my-engine')...)) >> engine = EngineUtility(url='sqlite:///') >> provideUtility(engine, IConnectable, 'my-engine') # but normally a >> local utility registration >> >> #myapplication/foo.py >> from myapplication import Session >> session = Session() > > Here one still needs to instantiate the session each time you use it. > Couldn't you simply do: > > #myapplication/__init__.py > ... [what you had] > session = Session() > > # myapplication/foo.py > from myapplication import session > > or wouldn't that be possible? No. It would be similar to doing: txn = transaction.get() (if we imagined for a moment that transactions were recyclable objects) Individual sessions are not thread safe. The point of a scoped session is that you get a different session depending on which thread you are in. >> One (perhaps the only) advantage I can see with looking up the scoped >> session as a utility is that it gives the integrator control over >> whether to use one or two phase commit, as this is set in the session >> configuration. Normally one would prefer one-phase commit as it is >> faster, but if an integrator arranged for two applications to be >> modified in a single transaction she would want to configure two-phase >> commit. > > How common would it be that the integrator would do this without the > code itself needing to be changed for other reasons then too? A WSGI > setup, perhaps? How long is a piece of string ;-) Elsewhere in this thread I have an imaginary departmental address book, one instance of the app per department. In this example the integrator would not have to change anything in the Address Book app. But then they want to create another app that allows them to search and replace across all address books. For this to work correctly they should reconfigure the address book app to use multiple two phase commit. > I imagine we could arrange something where we allow both. Provide the > engine as local utility scenario, but let people register sessions as > local utilities should they want to. Maybe this should be configured somewhere else than a local utility. I wander how Pylons does it. Laurence From mike_mp at zzzcomputing.com Wed May 7 14:04:40 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Wed May 7 14:04:42 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: On May 7, 2008, at 1:29 PM, Laurence Rowe wrote: > I'm thinking more about having the same classes mapped to different > databases at different points in the application. Imagine a > departmental address book app. Intstances of the departmental > address book are created for each department, each with a different > databases: > > http://addressbook/sales -> postgres:///sales > http://addressbook/engineering -> postgres:///engineering > > The way I imagine this working is to have a proxy engine object that > looks up the real engine through a local utility. Each application > would be a `site` and capable of local utility registrations. /sales > would have Engine('postgres:///sales') registered and /engineering > Engine('postgres:///engineering'). > > Only a single ScopedSession would be required. This would be bound > to proxy that performs the utility lookup. So when in the /sales > context the proxy would point to the sales engine and when in the / > engineering context to the engineering engine. > > The limitation of this approach is that it would not be possible to > mix objects from /sales and objects from /engineering into the same > transaction. So really we need a session per application instance. > Perhaps this can be achieved through a custom scoping function: > > def scopefunc(): > return thread.get_ident(), id(zope.component.getSiteManager()) If you want to mix tables (and optionally engines) for the *same* class, we actually have a feature for that too. Its sort of a feature I've wanted to remove but Jason keeps arguing that its worthy. It's called "entity_name" and it allows multiple primary mappers to be created for a single class. The entity_name has to be specified when you add the element to the session (yet another reason explicit add() is a good thing). This feature is taken directly from the Hibernate feature of the same name. The limitation with entity_name which needs some more fixing in 0.5 is that only one mapper gets to define the attribute instrumentation for the entity. If you are storing the same class in three different tables (across three different databases or just one), the attributes defined on the class need to be compatible with all three. This is reasonable since a class can only have one descriptor per attribute name. Querying is also slightly challenging since the descriptors need to be qualified for a particular mapper (i.e. you cant just say query.filter(Address.id==5)...which "id" are we talking about ?) The reason I'm not totally keen on this feature is that it seems to be a very exotic way of getting around making simple subclasses, and I've yet to see the use case for it where simple subclasses don't work, except for "cosmetic" reasons which I have a hard time swallowing (even if the reasons are "cosmetic", you can still create subclasses that are all "named" the same). So I will ask you, why can't your application simply have a SalesAddress and an EngineeringAddress class ? You could even produce them transparently using a custom __new__() method, i.e. class Address(object): def __new__(cls, *args, **kwargs): if my_scoped_thing.context == 'sales': return object.__new__(SalesAddress) elif my_scoped_thing.context == 'engineering': return object.__new__(EngineeringAddress) this seems extremely straightforward to me as each object, once instantiated is now bound for a specific destination. It doesnt seem like youd want the *same* Address to be stored in one and then the other in a different instance (that seems *extremely* complex for no good reason). Isnt explicit better than implicit ? From mborch at gmail.com Wed May 7 14:27:32 2008 From: mborch at gmail.com (Malthe Borch) Date: Wed May 7 14:27:38 2008 Subject: [Zope-dev] Re: Buildout Builder: Call for Ideas. In-Reply-To: <4821E826.8020903@gmail.com> References: <86C45136-A19E-4E4F-849E-CB1B2487A549@gmail.com> <4821E826.8020903@gmail.com> Message-ID: <4821F494.1040700@gmail.com> Malthe Borch wrote: > For^D^D^DFrom your application... From mborch at gmail.com Wed May 7 14:27:32 2008 From: mborch at gmail.com (Malthe Borch) Date: Wed May 7 14:27:41 2008 Subject: [Zope-dev] Re: Buildout Builder: Call for Ideas. In-Reply-To: <4821E826.8020903@gmail.com> References: <86C45136-A19E-4E4F-849E-CB1B2487A549@gmail.com> <4821E826.8020903@gmail.com> Message-ID: <4821F494.1040700@gmail.com> Malthe Borch wrote: > For^D^D^DFrom your application... From l at lrowe.co.uk Wed May 7 14:29:04 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 14:29:12 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Michael Bayer wrote: > So I will ask you, why can't your application simply have a SalesAddress > and an EngineeringAddress class ? You could even produce them > transparently using a custom __new__() method, i.e. > > class Address(object): > def __new__(cls, *args, **kwargs): > if my_scoped_thing.context == 'sales': > return object.__new__(SalesAddress) > elif my_scoped_thing.context == 'engineering': > return object.__new__(EngineeringAddress) > > this seems extremely straightforward to me as each object, once > instantiated is now bound for a specific destination. It doesnt seem > like youd want the *same* Address to be stored in one and then the other > in a different instance (that seems *extremely* complex for no good > reason). Isnt explicit better than implicit ? When the generic address book application is built you don't know what the departments will be called or indeed how many departments there are. An address book is not be a great example, but I know of intranet portal sites where this is a requirement. You want to delegate control to each department so you give each department their own instance of the portal. You only want to maintain one code base though, and you don't want to change it every time someone adds another departmental portal. I'd like to be able to create an add form that has fields for application name and database url. This probably seems like an odd requirement -- why not just run multiple processes with different configurations -- but it's the way zope has traditionally worked. A single process can serve multiple instances of the same application (or `site`). When you get up to running tens of sites, the memory footprint of Zope2 and Plone (before the object cache) becomes significant. Laurence From mike_mp at zzzcomputing.com Wed May 7 15:17:55 2008 From: mike_mp at zzzcomputing.com (Michael Bayer) Date: Wed May 7 15:17:59 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: On May 7, 2008, at 2:29 PM, Laurence Rowe wrote: > When the generic address book application is built you don't know > what the departments will be called or indeed how many departments > there are. An address book is not be a great example, but I know of > intranet portal sites where this is a requirement. You want to > delegate control to each department so you give each department > their own instance of the portal. You only want to maintain one code > base though, and you don't want to change it every time someone adds > another departmental portal. I'd like to be able to create an add > form that has fields for application name and database url. > > This probably seems like an odd requirement -- why not just run > multiple processes with different configurations -- but it's the way > zope has traditionally worked. A single process can serve multiple > instances of the same application (or `site`). When you get up to > running tens of sites, the memory footprint of Zope2 and Plone > (before the object cache) becomes significant. If you are running different instances each connected to a different engine within one process you wouldn't need any awareness of engines at the object level (therefore no entity_name) and also no engine proxying - you should have separate Session instances for each "process" managed by scoped_session(), which was designed to handle this. Multiple apps on one codebase within one process was an original requirement of Pylons as well, though nobody has ever used it. The easiest way to do it is to set up the engine at the request level: Session = scoped_session() # start of request engine = get_appropriate_engine() Session(bind=engine) try: # do request finally: Session.remove() If that isnt granular enough, then you use a custom scope func which maintains Session per-"process"-per-thread. From l at lrowe.co.uk Wed May 7 17:40:51 2008 From: l at lrowe.co.uk (Laurence Rowe) Date: Wed May 7 17:41:02 2008 Subject: [Zope-dev] Re: zope.sqlalchemy In-Reply-To: References: <2E03DFE0-F2E2-44D9-A1F0-F81973BC6E8A@zzzcomputing.com> <20080506215501.GB15736@mindy> Message-ID: Laurence Rowe wrote: > Martijn Faassen wrote: >> Hey Laurence, >> >> Laurence Rowe wrote: >> [snip] >>> We'll have to stick with scoped sesssions because of threading, but >>> the engine as local utility pattern should still work. >>> >>> #myapplication/__init__.py >>> Session = >>> scoped_session(sessionmaker(bind=LookupEngine('my-engine')...)) >>> engine = EngineUtility(url='sqlite:///') >>> provideUtility(engine, IConnectable, 'my-engine') # but normally a >>> local utility registration >>> >>> #myapplication/foo.py >>> from myapplication import Session >>> session = Session() Would session = ISession(context) be a reasonable way for grok to handle this? Making transactions span multiple instances of a single app seems impossible otherwise, though maybe that is an edge case that need not be supported. Laurence From m.van.rees at zestsoftware.nl Wed May 7 18:13:12 2008 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Wed May 7 18:13:23 2008 Subject: [Zope-dev] Re: AW: Re: New i18n locale extraction concept References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <4819B6B6.8070903@free.fr> <014f01c8abd3$addcb170$0409a8c0@mobile04> Message-ID: Hi Roger, Roger Ineichen, on 2008-05-01: > I agree, a tool whould be great. But the first we need to > offer i18n extract script which can handle our new egg > based buildout process. z3c.recipe.i18n is the only one > which could handle this right now. > >> Ideally, the recipe i18n tool should be able to extract, >> merge, and give stats, just like in the monolithic zope release. > > Yes, z3c.recipe.i18n does this right now. The -d option uses > one or more egg or develop externals as argument instead of > one single path. Some comments on that z3c.recipe.i18n In README.txt you first mention z3c.recipe.start, then the i18n recipe and then the app recipe. Is the same meant in all three cases? I like that it can extract locales from eggs. I don't like that it uses zcml for this. Is the zcml really necessary? Why specify both eggs and packages? And why specify those packages in the setup.py too? At least that is what I see in zam.locales. The tests don't run on Linux as there are Windows specific checks in them, for example: File ".../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt", line 121, in README.txt Failed example: ls('bin') Expected: - buildout-script.py - buildout.exe - i18nextract-script.py - i18nextract.exe - i18nmergeall-script.py - i18nmergeall.exe - i18nstats-script.py - i18nstats.exe Got: - buildout - i18nextract - i18nmergeall - i18nstats Of course quite likely there are also a lot of Linux/Mac packages that fail on Windows because of similar reasons. :-/ -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] From dev at projekt01.ch Wed May 7 18:55:06 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Wed May 7 18:54:04 2008 Subject: AW: [Zope-dev] Re: AW: Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <4819B6B6.8070903@free.fr><014f01c8abd3$addcb170$0409a8c0@mobile04> Message-ID: <003a01c8b095$65aa62a0$8124fea9@mobile04> Hi Maurits Thanks for your feedback, > Betreff: [Zope-dev] Re: AW: Re: New i18n locale extraction concept > > Hi Roger, > > Roger Ineichen, on 2008-05-01: > > I agree, a tool whould be great. But the first we need to > offer i18n > > extract script which can handle our new egg based buildout process. > > z3c.recipe.i18n is the only one which could handle this right now. > > > >> Ideally, the recipe i18n tool should be able to extract, > merge, and > >> give stats, just like in the monolithic zope release. > > > > Yes, z3c.recipe.i18n does this right now. The -d option uses one or > > more egg or develop externals as argument instead of one > single path. > > Some comments on that z3c.recipe.i18n > > In README.txt you first mention z3c.recipe.start, then the > i18n recipe and then the app recipe. Is the same meant in > all three cases? Uhaaa, that's a left over from a copied README.txt file. I need to review that part again. > I like that it can extract locales from eggs. I don't like > that it uses zcml for this. Is the zcml really necessary? zcml is needed for exctract locales from page templates. > Why specify both eggs and packages? And why specify those > packages in the setup.py too? At least that is what I see in > zam.locales. Eggs are needed for setup your project, or probably a working setup like in any other package. Packages are used for extract locales from. That could be very different then the egg setup. The i18nextrac.py will only deep into this packages, but probably this packages will need different eggs which they import from. Note, if you run the i18nextract script, all module must be there like in a running application. You can't only use the files which will contain locales. Also modules which this packages import from must be there. This isn't aproblem since the zope.app.locales dependes on everyting which we developed the last years. Because zope.app.locales depends on almost everything. > The tests don't run on Linux as there are Windows specific > checks in them, for example: > > File ".../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt", line 121, > in README.txt > Failed example: > ls('bin') > Expected: > - buildout-script.py > - buildout.exe > - i18nextract-script.py > - i18nextract.exe > - i18nmergeall-script.py > - i18nmergeall.exe > - i18nstats-script.py > - i18nstats.exe > Got: > - buildout > - i18nextract > - i18nmergeall > - i18nstats > > Of course quite likely there are also a lot of Linux/Mac > packages that fail on Windows because of similar reasons. :-/ I see, I 'll add a normalizer for that. I thought it was already there, but could be not correct implemented. Regards Roger Ineichen > -- > Maurits van Rees | http://maurits.vanrees.org/ > Work | http://zestsoftware.nl/ "This is your day, > don't let them take it away." [Barlow Girl] > > _______________________________________________ > 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 ) > From ct at gocept.com Thu May 8 05:55:39 2008 From: ct at gocept.com (Christian Theune) Date: Thu May 8 05:55:43 2008 Subject: [Zope-dev] Common-Criteria certification cancelled Message-ID: <20080508095539.GG6648@mindy> Hi everyone, I have to give an unfortunate update about the Common Criteria (CC) certification. The CC project began in 2003 to certify Zope 3's security architecture under the conditions of the Common Criteria framework. We started out as a community effort which turned out not to be a viable solution due to the lack of interest of volunteers and the complexity of the problem space. gocept restarted the efforts in 2006 and provided a security target document which was given to review and moving pretty good actually. There were very concrete and viable plans for 2008 to finally get the certification wrapped up by end of may. Unfortunately the project had to be cancelled due to the lack of interest of the sponsoring organisation which went through a major merger. Due to that we're stopping all activities on the certification. If interest in this should come back at some point, we'd be happy to be part of a renewed effort. Christian -- gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle (saale) - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development From zope-tests at epy.co.at Thu May 8 07:00:06 2008 From: zope-tests at epy.co.at (Zope Tests Summarizer) Date: Thu May 8 07:00:06 2008 Subject: [Zope-dev] Zope Tests: 5 OK Message-ID: <200805081100.m48B06tF014959@shnoll.test.at> Summary of messages to the zope-tests list. Period Wed May 7 11:00:00 2008 UTC to Thu May 8 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Wed May 7 21:01:04 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009515.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Wed May 7 21:02:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009516.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Wed May 7 21:04:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009517.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Wed May 7 21:05:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009518.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Wed May 7 21:07:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-May/009519.html From srichter at cosmos.phy.tufts.edu Thu May 8 11:07:09 2008 From: srichter at cosmos.phy.tufts.edu (Stephan Richter) Date: Thu May 8 11:07:21 2008 Subject: AW: [Zope-dev] Re: AW: Re: New i18n locale extraction concept In-Reply-To: <003a01c8b095$65aa62a0$8124fea9@mobile04> References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <003a01c8b095$65aa62a0$8124fea9@mobile04> Message-ID: <200805080807.09606.srichter@cosmos.phy.tufts.edu> On Wednesday 07 May 2008, Roger Ineichen wrote: > > I like that it can extract locales from eggs. ?I don't like > > that it uses zcml for this. ?Is the zcml really necessary? > > zcml is needed for exctract locales from page templates. ? ZCML is needed to extract strings from ZCML. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter" From m.van.rees at zestsoftware.nl Thu May 8 12:55:17 2008 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Thu May 8 12:55:33 2008 Subject: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <003a01c8b095$65aa62a0$8124fea9@mobile04> <200805080807.09606.srichter@cosmos.phy.tufts.edu> Message-ID: Stephan Richter, on 2008-05-08: > On Wednesday 07 May 2008, Roger Ineichen wrote: >> > I like that it can extract locales from eggs. ?I don't like >> > that it uses zcml for this. ?Is the zcml really necessary? >> >> zcml is needed for exctract locales from page templates. ? > > ZCML is needed to extract strings from ZCML. I am looking at maybe using this recipe in grokproject. Having that zcml be *required* (which it currently is in that recipe) is a no-no for us simple Grok folks. ;-) I hope it is possible to remove that zcml requirement; the recipe is still young, so who knows. I am also looking at i18ndude for that, as that is what I have been using in Plone-land so far. Might work nicely in the Grok-cave too. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] From m.van.rees at zestsoftware.nl Thu May 8 13:16:19 2008 From: m.van.rees at zestsoftware.nl (Maurits van Rees) Date: Thu May 8 13:16:32 2008 Subject: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <4819B6B6.8070903@free.fr> <014f01c8abd3$addcb170$0409a8c0@mobile04> <003a01c8b095$65aa62a0$8124fea9@mobile04> Message-ID: Hi Roger, Roger Ineichen, on 2008-05-07: > Uhaaa, that's a left over from a copied README.txt file. > I need to review that part again. I thought it might be something like that. :-) >> Why specify both eggs and packages? And why specify those >> packages in the setup.py too? At least that is what I see in >> zam.locales. > > Eggs are needed for setup your project, or probably a working > setup like in any other package. > > Packages are used for extract locales from. That could be very > different then the egg setup. The i18nextrac.py will only deep > into this packages, but probably this packages will need different > eggs which they import from. I would hope that it is possible to just list the eggs that you are interested in, have buildout install all their requirements (as listed in their setup.py) and have the recipe only extract message ids from those original eggs without their dependencies. Then the 'packages' directive would not be necessary anymore. Or perhaps when the packages option is empty, it takes the value of the eggs option as default. I do not know if this is possible and I have not gone in with a pdb to check it. > Note, if you run the i18nextract script, all module must be > there like in a running application. You can't only use > the files which will contain locales. Also modules which > this packages import from must be there. That should not be necessary I think. At least I am not used to it. When I use i18ndude for making pot/po files for a Plone product/package and I have "from Products.CMFPlone import something" in a file, then this import does not really take place. I expect in the case of python files it simply looks for lines like: _(u"My message to the world.") > This isn't aproblem since the zope.app.locales dependes on > everyting which we developed the last years. Because > zope.app.locales depends on almost everything. Do you envision using this recipe also for translating a single package? Or is your target really only big software collections like zope.app.*? I wonder a bit if it makes the second use case possible by making the first use case harder. It worked fine when I tried it on zam.locales btw, except that all lines in the resulting .pot file were changed, but that is because of Windows versus Unix line endings in subversion, which has nothing to do with this recipe. > I see, I 'll add a normalizer for that. I thought it was already > there, but could be not correct implemented. If you have a fix for that and you need me to test that on Linux, let me know. Cheers and thanks, -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl] From joshjohnson.cpc at gmail.com Thu May 8 13:39:41 2008 From: joshjohnson.cpc at gmail.com (Josh Johnson (jjmojojjmojo)) Date: Thu May 8 13:39:47 2008 Subject: [Zope-dev] OrderedMultiSelectWidget in Zope2: context weirdness? Message-ID: <48233ADD.4040903@gmail.com> I'm looking at the code for OrderedMultiSelectWidget, in zope.app.form.browser.itemswidgets (line 535). This code doesn't make sense to me: if hasattr(self.context.context, self.context.__name__): available_values = self.context.get(self.context.context) else: available_values = [] From what I can tell, this code is grabbing anything on the current content/view that's named the same as the name of the vocabulary provider. This bit me earlier with this error: Traceback (innermost last): Module ZPublisher.Publish, line 119, in publish Module ZPublisher.mapply, line 88, in mapply Module ZPublisher.Publish, line 42, in call_object Module zope.formlib.form, line 770, in __call__ Module zope.formlib.form, line 764, in render Module plone.app.form._named, line 26, in __call__ Module Shared.DC.Scripts.Bindings, line 313, in __call__ Module Shared.DC.Scripts.Bindings, line 350, in _bindAndExec Module Products.PageTemplates.PageTemplateFile, line 129, in _exec Module Products.PageTemplates.PageTemplate, line 89, in pt_render Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 891, in do_useMacro Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 536, in do_optTag_tal Module zope.tal.talinterpreter, line 521, in do_optTag Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 891, in do_useMacro Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 536, in do_optTag_tal Module zope.tal.talinterpreter, line 521, in do_optTag Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 957, in do_defineSlot Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 536, in do_optTag_tal Module zope.tal.talinterpreter, line 521, in do_optTag Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 861, in do_defineMacro Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 949, in do_defineSlot Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 536, in do_optTag_tal Module zope.tal.talinterpreter, line 521, in do_optTag Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 949, in do_defineSlot Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 861, in do_defineMacro Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 861, in do_defineMacro Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 957, in do_defineSlot Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 534, in do_optTag_tal Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 824, in do_loop_tal Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 536, in do_optTag_tal Module zope.tal.talinterpreter, line 521, in do_optTag Module zope.tal.talinterpreter, line 516, in no_tag Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 745, in do_insertStructure_tal Module Products.PageTemplates.Expressions, line 221, in evaluateStructure Module zope.tales.tales, line 696, in evaluate - URL: pageform - Line 104, Column 10 - Expression: - Names: {'container': , 'context': , 'default': , 'here': , 'loop': {'widget': }, 'nothing': None, 'options': {'args': ()}, 'repeat': , 'request': , 'root': , 'template': , 'traverse_subpath': [], 'user': , 'view': , 'views': } Module zope.tales.expressions, line 217, in __call__ Module Products.PageTemplates.Expressions, line 161, in _eval Module Products.PageTemplates.Expressions, line 123, in render Module zope.app.form.browser.itemswidgets, line 568, in __call__ Module zope.app.pagetemplate.viewpagetemplatefile, line 83, in __call__ Module zope.app.pagetemplate.viewpagetemplatefile, line 51, in __call__ Module zope.pagetemplate.pagetemplate, line 117, in pt_render Module zope.tal.talinterpreter, line 271, in __call__ Module zope.tal.talinterpreter, line 346, in interpret Module zope.tal.talinterpreter, line 822, in do_loop_tal Module zope.tales.tales, line 682, in setRepeat Module zope.tales.tales, line 696, in evaluate - URL: /xxxxxxxxxxxxxxxxx/parts/zope2/lib/python/zope/app/form/browser/orderedSelectionList.pt - Line 146, Column 8 - Expression: - Names: {'args': (), 'context': , 'default': , 'loop': {}, 'nothing': None, 'options': {}, 'repeat': {}, 'request': , 'template': , 'usage': , 'view': , 'views': } Module zope.tales.expressions, line 217, in __call__ Module zope.tales.expressions, line 211, in _eval Module zope.app.form.browser.itemswidgets, line 547, in choices TypeError: iterable argument required I had a named utility that was mapped to a function called 'activities' which provides IVocabularyFactory. I had a browser form page that had a field in it that used that named utility. The form class had a method on it called 'activities'. Through some pdb digging, I was able to figure out that it was grabbing the view method and not the function. It makes sense looking at the code, but why would it work that way? Am I looking at this wrong, or is this a bug? My setup : Plone 3.0.6 (according to Plone control pannel.. it's supposed to be 3.1.1) CMF 2.1.1 Zope (Zope 2.10.5-final, python 2.4.3, linux2) Python 2.4.3 (#2, Mar 7 2008, 01:58:20) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] PIL 1.1.5 Five 1.5.6 I can put together some example code to reproduce the issue, if necessary. Thanks, JJ From jim at zope.com Thu May 8 14:02:43 2008 From: jim at zope.com (Jim Fulton) Date: Thu May 8 14:02:58 2008 Subject: AW: [Zope-dev] Re: Heads up - package lost on pypi! In-Reply-To: <010101c8b053$b4a97e00$0409a8c0@mobile04> References: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04><4821BB15.7000207@zeomega.com> <010101c8b053$b4a97e00$0409a8c0@mobile04> Message-ID: <6896CCEC-30EC-4CB6-897F-FFD6F82C7911@zope.com> On May 7, 2008, at 11:04 AM, Roger Ineichen wrote: > Hi > >> Betreff: [Zope-dev] Re: Heads up - package lost on pypi! >> >> Baiju M wrote: >>> Roger Ineichen wrote: >>>> Hi all >>>> >>>> The z3c.configurator package is gone on PyPi. >>>> >>>> Does sombody know what's happen? And more important, how can we >>>> recover this? >>> >>> AFAIK, only owners can delete it. >>> May be deleted by an owner by mistake. >>> I am not sure whether we can recover it. >> >> Are really sure it ever existed? >> >> Googling for: >> >> "http://pypi.python.org/pypi/z3c.configurator" >> >> didnt' return any obvious hits. Doesn't mean much, it might >> not have made it to the index. Note that there is a >> z3c.configurator upload here: >> >> http://download.zope.org/distribution/ > > hehe, > I guess you are right. Seems that the package never exist > on pypi. bad, bad I wouldn't assume that. One of my packages, buildoutsftp has gone missing too. :( I'm gonna re-upload the latest release now. Jim -- Jim Fulton Zope Corporation From jim at zope.com Thu May 8 14:04:55 2008 From: jim at zope.com (Jim Fulton) Date: Thu May 8 14:05:04 2008 Subject: AW: [Zope-dev] Re: Heads up - package lost on pypi! In-Reply-To: <6896CCEC-30EC-4CB6-897F-FFD6F82C7911@zope.com> References: <00eb01c8b04c$fdb12ff0$0409a8c0@mobile04><4821BB15.7000207@zeomega.com> <010101c8b053$b4a97e00$0409a8c0@mobile04> <6896CCEC-30EC-4CB6-897F-FFD6F82C7911@zope.com> Message-ID: <763C6CC0-3591-4BCF-801F-2E76CA99FFA2@zope.com> I wrote: > I wouldn't assume that. One of my packages, buildoutsftp has gone > missing too. :( Never mind. I was looking for the wrong package name. :/ Jim -- Jim Fulton Zope Corporation From fairwinds at eastlink.ca Thu May 8 14:54:59 2008 From: fairwinds at eastlink.ca (David Pratt) Date: Thu May 8 14:55:01 2008 Subject: [Zope-dev] Building on python 2.5 - any progress? Message-ID: <48234C83.4030606@eastlink.ca> Hi. I am wondering if there was any further resolution to builds with python 2.5 as discussed in the following articles: http://mail.zope.org/pipermail/zope3-users/2007-September/006909.html http://mail.zope.org/pipermail/zope3-users/2007-September/006916.html In addition to the warnings concerning initialization from incompatible pointer type, there are numerous warnings about intargfunc and intintargfunc being deprecated also. I am building on mac osx and run into these issues also. I am becoming a bit more concerned about moving to 2.5 as opposed to 2.4 for my work. Anyone building on a platform that has not posed this problem. Any compiler flags to python or recommendation for a different compiler that may help with this. Many thanks. Regards, David From dev at projekt01.ch Thu May 8 19:08:55 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Thu May 8 19:07:52 2008 Subject: AW: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04><003a01c8b095$65aa62a0$8124fea9@mobile04><200805080807.09606.srichter@cosmos.phy.tufts.edu> Message-ID: <008101c8b160$7e6a4690$0409a8c0@mobile04> Hi Maurits > -----Urspr?ngliche Nachricht----- > Von: zope-dev-bounces@zope.org > [mailto:zope-dev-bounces@zope.org] Im Auftrag von Maurits van Rees > Gesendet: Donnerstag, 8. Mai 2008 18:55 > An: zope-dev@zope.org > Betreff: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale > extraction concept > > Stephan Richter, on 2008-05-08: > > On Wednesday 07 May 2008, Roger Ineichen wrote: > >> > I like that it can extract locales from eggs. ?I don't > like that it > >> > uses zcml for this. ?Is the zcml really necessary? > >> > >> zcml is needed for exctract locales from page templates. > > > > ZCML is needed to extract strings from ZCML. > > I am looking at maybe using this recipe in grokproject. > Having that zcml be *required* (which it currently is in that > recipe) is a no-no for us simple Grok folks. ;-) > > I hope it is possible to remove that zcml requirement; the > recipe is still young, so who knows. I am also looking at > i18ndude for that, as that is what I have been using in > Plone-land so far. Might work nicely in the Grok-cave too. The goal of this package is to allow to translate projects or shared translation from package namspaces which was not possible right now. I see your point not having zcml but that's a no go for use since most zope project are using ZCML. But probably we can find a way out of this. I really need to take a closer look at everything first. Some hints, the package offers translation support and uses additional extra_requires for the configuration. In prodution you whould never define such extra_requires in a buildout and then you will never get such zcml dependencies. Does that not fit for grok. Or are you using the same buildout for development and production usage? I hope not right? Regards Roger Ineichen > -- > Maurits van Rees | http://maurits.vanrees.org/ > Work | http://zestsoftware.nl/ "This is your day, > don't let them take it away." [Barlow Girl] > > _______________________________________________ > 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 ) > From dev at projekt01.ch Thu May 8 19:32:54 2008 From: dev at projekt01.ch (Roger Ineichen) Date: Thu May 8 19:31:50 2008 Subject: AW: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept In-Reply-To: References: <004f01c8ab1f$2e167a20$8124fea9@mobile04> <4819B6B6.8070903@free.fr><014f01c8abd3$addcb170$0409a8c0@mobile04><003a01c8b095$65aa62a0$8124fea9@mobile04> Message-ID: <008501c8b163$d7e707a0$0409a8c0@mobile04> Hi Maurits > Betreff: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale > extraction concept [...] > > Packages are used for extract locales from. That could be very > > different then the egg setup. The i18nextrac.py will