[Zope-dev] [z3c.recipe.i18n] Review of Buildout 2 support
Hi, Does anyone can review or merge the PR please? https://github.com/zopefoundation/z3c.recipe.i18n/pull/1 -- Sebastien Douche Twitter: @sdouche / G+: +sdouche ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n
On 10/6/10 10:27 AM, Jan-Wijbrand Kolman wrote: > On 10/6/10 9:53 AM, yuppie wrote: >> Jan-Wijbrand Kolman wrote: >>> This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The >>> recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to >>> release this merge as 0.8.0 as this make it possible to move grok and >>> the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful >>> in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. >>> >>> Unless there are objections of course :) >> >> +1 >> >> But could you please make it more explicit that 0.8.0 drops support for >> zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe >> install_requires should specify the new requirement explicitly. > > Yes, agreed. Released as 0.80. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n
On 10/6/10 9:53 AM, yuppie wrote: > Jan-Wijbrand Kolman wrote: >> This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The >> recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to >> release this merge as 0.8.0 as this make it possible to move grok and >> the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful >> in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. >> >> Unless there are objections of course :) > > +1 > > But could you please make it more explicit that 0.8.0 drops support for > zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe > install_requires should specify the new requirement explicitly. Yes, agreed. regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n
On 10/6/10 09:53 , yuppie wrote: > Hi! > > > Jan-Wijbrand Kolman wrote: >> This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The >> recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to >> release this merge as 0.8.0 as this make it possible to move grok and >> the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful >> in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. >> >> Unless there are objections of course :) > > +1 > > But could you please make it more explicit that 0.8.0 drops support for > zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe > install_requires should specify the new requirement explicitly. I'ld even go so far as to say install_requires must specify such a requirement. Wichert. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n
Hi! Jan-Wijbrand Kolman wrote: > This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The > recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to > release this merge as 0.8.0 as this make it possible to move grok and > the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful > in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. > > Unless there are objections of course :) +1 But could you please make it more explicit that 0.8.0 drops support for zc.buildout 1.4? Your CHANGES.txt note is not clear about that and maybe install_requires should specify the new requirement explicitly. BTW: I just fixed some failing tests on Windows. Hope that doesn't mask any real issues. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.recipe.i18n
Hi, This afternoon I merged the "gary-0.8.0" branch for z3c.recipe.i18n. The recipe now uses and depends on zc.buildout-1.5.1 features. I'd like to release this merge as 0.8.0 as this make it possible to move grok and the groktoolkit over to zc.buildout-1.5.1. I guess this is also useful in the light of moving the ZTK itself to zc.buildout 1.5.1 at some point. Unless there are objections of course :) regards, jw ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote: > On 2009-12-01 16:36:50 +0100, yuppie said: >> Christian Zagrodnick wrote: >>> AttributeError: 'NoneType' object has no attribute 'location' >> Should be fixed now. Yuppie > > Thanks! And it was such an easy fix! :) Well. Actually I didn't test with a clean buildout and removed 'zope.contenttype' as well because it wasn't part of my dependencies. But you noticed and fixed that already :) Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests fail
On 2009-12-01 16:36:50 +0100, yuppie said: > Christian Zagrodnick wrote: >> Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt >> Traceback (most recent call last): >> File "/Users/zagy/development/python/lib/python2.6/unittest.py", line >> 270, in run >> self.setUp() >> File >> "/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py", line >> >> 2289, in setUp >> self._dt_setUp(test) >> File "/private/tmp/trunk/src/z3c/recipe/i18n/tests.py", line 43, in setUp >> zc.buildout.testing.install('zope.app.publisher', test) >> File >> "/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py", line >> >> 464, in install >> if dist.location.endswith('.egg'): >> AttributeError: 'NoneType' object has no attribute 'location' > > Should be fixed now. Yuppie Thanks! And it was such an easy fix! :) -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests fail
Christian Zagrodnick wrote: > Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt > Traceback (most recent call last): > File "/Users/zagy/development/python/lib/python2.6/unittest.py", line > 270, in run > self.setUp() > File > "/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py", > > line 2289, in setUp > self._dt_setUp(test) > File "/private/tmp/trunk/src/z3c/recipe/i18n/tests.py", line 43, in setUp > zc.buildout.testing.install('zope.app.publisher', test) > File > "/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py", > > line 464, in install > if dist.location.endswith('.egg'): > AttributeError: 'NoneType' object has no attribute 'location' Should be fixed now. Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.recipe.i18n tests fail
Hi, the tests fail with the following error: Running zope.testing.testrunner.layer.UnitTests tests: Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds. Error in test /private/tmp/trunk/src/z3c/recipe/i18n/README.txt Traceback (most recent call last): File "/Users/zagy/development/python/lib/python2.6/unittest.py", line 270, in run self.setUp() File "/Users/zagy/development/eggs/zope.testing-3.8.3-py2.6.egg/zope/testing/doctest.py", line 2289, in setUp self._dt_setUp(test) File "/private/tmp/trunk/src/z3c/recipe/i18n/tests.py", line 43, in setUp zc.buildout.testing.install('zope.app.publisher', test) File "/Users/zagy/development/eggs/zc.buildout-1.4.2-py2.6.egg/zc/buildout/testing.py", line 464, in install if dist.location.endswith('.egg'): AttributeError: 'NoneType' object has no attribute 'location' I actually have no idea why this is happening. Anybody got a clue? Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: 5. writing makers - Proposal: Pass in the additional arguments and fall back >> to the old signature for BBB. >> Done. I also added site_zcml as argument. >> >> What about wrapping py_strings, zcml_strings and tal_strings >> in functions that implement the new interface? This would >> make it possible to add them to the makers list and call them >> in the same loop. > > Yes, why not. Probably we should do this together with a > refactoring and change/enhance the method signature for > the pot makers. I'm not sure I understand what you mean. What exactly do you want to change/enhance? This checkin already changed/enhanced the way pot makers are called: http://svn.zope.org/?rev=101958&view=rev Do you want to improve that further or do you propose to modify py_strings, zcml_strings and tal_strings? They all have currently different signatures. I can't see a way to unify that in a backwards compatible way. That's why I proposed to wrap them in new z3c.recipe.i18n specific functions. I propose I start with the changes I have in mind. Of course you can improve that further after I'm done. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie > Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract > > Hi Roger! > > > >> 1.) running tests > >> - > >> > >> Proposal: Remove those two lines in test.py. > > Done. > > >> 2.) looking up the product version > >> -- > >> > >> Proposal: Catch the error. Return an empty string if > version is not > >> found. > > The problem was somewhere different: Caused by wrong > dependencies zope.app.applicationcontrol was not available. > After fixing the dependencies the method works without error > and 'Development/Unknown' is returned with Zope 2. That's > sufficient for me. > > >> 3.) customizing the .pot header > >> --- > >> > >> Proposal: The easiest and most flexible way to customize > this seems > >> to be an option that allows to specify a file that contains the > >> pot_header template. > > This is still missing. I plan to subclass POTMaker in > z3c.recipe.i18n instead of modifying zope.app.locales.extract. > > >> 4.) looking up basePath > >> --- > >> > >> Proposal: Use the 'if' code for all packages. > > Done. (At least if nobody complains.) > > >> 5. writing makers > >> - > >> > >> Proposal: Pass in the additional arguments and fall back > to the old > >> signature for BBB. > > Done. I also added site_zcml as argument. > > What about wrapping py_strings, zcml_strings and tal_strings > in functions that implement the new interface? This would > make it possible to add them to the makers list and call them > in the same loop. Yes, why not. Probably we should do this together with a refactoring and change/enhance the method signature for the pot makers. Regards Roger Ineichen _ END OF MESSAGE ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger! >> 1.) running tests >> - >> >> Proposal: Remove those two lines in test.py. Done. >> 2.) looking up the product version >> -- >> >> Proposal: Catch the error. Return an empty string if version >> is not found. The problem was somewhere different: Caused by wrong dependencies zope.app.applicationcontrol was not available. After fixing the dependencies the method works without error and 'Development/Unknown' is returned with Zope 2. That's sufficient for me. >> 3.) customizing the .pot header >> --- >> >> Proposal: The easiest and most flexible way to customize this >> seems to be an option that allows to specify a file that >> contains the pot_header template. This is still missing. I plan to subclass POTMaker in z3c.recipe.i18n instead of modifying zope.app.locales.extract. >> 4.) looking up basePath >> --- >> >> Proposal: Use the 'if' code for all packages. Done. (At least if nobody complains.) >> 5. writing makers >> - >> >> Proposal: Pass in the additional arguments and fall back to >> the old signature for BBB. Done. I also added site_zcml as argument. What about wrapping py_strings, zcml_strings and tal_strings in functions that implement the new interface? This would make it possible to add them to the makers list and call them in the same loop. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: >> What about testing it like this: >> >> We remove the 'else' part and wait until someone complains. >> In that case we have a scenario for testing and fixing the >> issue. If nobody complains, the 'else' part was indeed useless. >> >> The current code doesn't work for me because 'src' is found >> but not the right place to split the path. > > I'm fine with that. I can test the changes with the project > which I used as base when I wrote the path cleanup code. I checked in that change. Can you please test? Thanks! Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie > Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract > > Hi Roger, > > > Thanks for your feedback! > > Roger Ineichen wrote: > >> -Ursprüngliche Nachricht- > >> 2.) looking up the product version > >> -- > >> > >> POTMaker._getProductVersion() doesn't work for me. > >> zope.app.applicationcontrol is not used by Zope 2 and is > not part of > >> the specified dependencies. This raises an error. > >> > >> Proposal: Catch the error. Return an empty string if > version is not > >> found. > > > > Sounds good to me as a workarround > > > > Probably we should try to use the package version of the egg which > > uses the i18n recipe? > > Not every buildout is itself an egg. So in any case we need a > fallback. > > In my use case I plan to set the version manually in the > pot_header template. So I don't need the version lookup. Agreed, sound good to me. > i18nextract.main() initializes POTMaker this way: > > # setup pot maker > maker = POTMaker(output_file, '') > > The second argument is the path that is used by > POTMaker._getProductVersion() to look up a 'version.txt' > file. Maybe we could use a better path than ''. But I'll > leave it to someone else to figure that out. I'm not sure and didn't look at the code but I guess the existing zope implementation depends on subversion get version info or something like that. This pattern is probably totaly out of date since we use buildout and eggs. > >> 4.) looking up basePath > >> --- > >> > >> i18nextract.main() contains these lines: > >> > >> # add maker for each given path > >> for pkgName, path in eggPaths: > >> srcIdx = path.rfind('src') > >> if srcIdx == -1: > >> # this is an egg package, strip down base path > >> basePath = path > >> moduleNames = pkgName.split('.') > >> moduleNames.reverse() > >> for mName in moduleNames: > >> mIdx = path.rfind(mName) > >> basePath = basePath[:mIdx] > >> pkgPath = path[len(basePath):] > >> else: > >> # this is a package linked in as externals > >> basePath = path[:srcIdx] > >> pkgPath = path[len(basePath):] > >> > >> I don't understand why we need different code for > "packages linked in > >> as externals". The "egg package" code works actually better for > >> linked in packages that don't follow the 'src' convention. > >> > >> Proposal: Use the 'if' code for all packages. > > > > I was fighting several times with this part during coding. > > The only thing which this part has to make sure is that we > do not use > > anything outside of the package in our path. > > > > The reason for not including everything outside the package in our > > path is that such a path whould be depend on the local setup e.g. > > > > D:\foo\dev\zope\session:3 > > > > We only have to make sure that this never will happen and > that we for > > each use case generate path like: > > > > zope/session.py:3 > > > > It could be that the if part is working for all usecases. > > but I'n not sure without debugging. > > Debugging doesn't help much if we don't know all use cases. Yes, that's true > What about testing it like this: > > We remove the 'else' part and wait until someone complains. > In that case we have a scenario for testing and fixing the > issue. If nobody complains, the 'else' part was indeed useless. > > The current code doesn't work for me because 'src' is found > but not the right place to split the path. I'm fine with that. I can test the changes with the project which I used as base when I wrote the path cleanup code. Agreed, using "src" as a hard coded name can end in a bad result. Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger, Thanks for your feedback! Roger Ineichen wrote: >> -Ursprüngliche Nachricht- >> 2.) looking up the product version >> -- >> >> POTMaker._getProductVersion() doesn't work for me. >> zope.app.applicationcontrol is not used by Zope 2 and is not >> part of the specified dependencies. This raises an error. >> >> Proposal: Catch the error. Return an empty string if version >> is not found. > > Sounds good to me as a workarround > > Probably we should try to use the package version of the egg > which uses the i18n recipe? Not every buildout is itself an egg. So in any case we need a fallback. In my use case I plan to set the version manually in the pot_header template. So I don't need the version lookup. i18nextract.main() initializes POTMaker this way: # setup pot maker maker = POTMaker(output_file, '') The second argument is the path that is used by POTMaker._getProductVersion() to look up a 'version.txt' file. Maybe we could use a better path than ''. But I'll leave it to someone else to figure that out. >> 4.) looking up basePath >> --- >> >> i18nextract.main() contains these lines: >> >> # add maker for each given path >> for pkgName, path in eggPaths: >> srcIdx = path.rfind('src') >> if srcIdx == -1: >> # this is an egg package, strip down base path >> basePath = path >> moduleNames = pkgName.split('.') >> moduleNames.reverse() >> for mName in moduleNames: >> mIdx = path.rfind(mName) >> basePath = basePath[:mIdx] >> pkgPath = path[len(basePath):] >> else: >> # this is a package linked in as externals >> basePath = path[:srcIdx] >> pkgPath = path[len(basePath):] >> >> I don't understand why we need different code for "packages >> linked in as externals". The "egg package" code works >> actually better for linked in packages that don't follow the >> 'src' convention. >> >> Proposal: Use the 'if' code for all packages. > > I was fighting several times with this part during coding. > The only thing which this part has to make sure is that > we do not use anything outside of the package in our path. > > The reason for not including everything outside the package > in our path is that such a path whould be depend on the > local setup e.g. > > D:\foo\dev\zope\session:3 > > We only have to make sure that this never will happen and that > we for each use case generate path like: > > zope/session.py:3 > > It could be that the if part is working for all usecases. > but I'n not sure without debugging. Debugging doesn't help much if we don't know all use cases. What about testing it like this: We remove the 'else' part and wait until someone complains. In that case we have a scenario for testing and fixing the issue. If nobody complains, the 'else' part was indeed useless. The current code doesn't work for me because 'src' is found but not the right place to split the path. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi yuppie > -Ursprüngliche Nachricht- > Von: zope-dev-bounces+dev=projekt01...@zope.org > [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im > Auftrag von yuppie > Gesendet: Mittwoch, 15. Juli 2009 21:04 > An: Zope-Dev List > Betreff: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract > > Hi! > > > I plan to use z3c.recipe.i18n for some Zope 2 CMF products. > But to get things working I did have to modify z3c.recipe.i18n a bit. > > It would be nice if I could get some feedback regarding the > issues I found: > > 1.) running tests > - > > test.py tries to install 'zodbcode' and 'zope.app.interface'. > That doesn't work for me. AFAICS those two eggs are no longer > indirect testing dependencies. After removing those two lines > all tests pass. > > Proposal: Remove those two lines in test.py. That's fine > 2.) looking up the product version > -- > > POTMaker._getProductVersion() doesn't work for me. > zope.app.applicationcontrol is not used by Zope 2 and is not > part of the specified dependencies. This raises an error. > > Proposal: Catch the error. Return an empty string if version > is not found. Sounds good to me as a workarround Probably we should try to use the package version of the egg which uses the i18n recipe? > 3.) customizing the .pot header > --- > > POTMaker.write() uses a harcoded Zope 3 specific pot_header template. > > Proposal: The easiest and most flexible way to customize this > seems to be an option that allows to specify a file that > contains the pot_header template. Yeah, that's a nice option > 4.) looking up basePath > --- > > i18nextract.main() contains these lines: > > # add maker for each given path > for pkgName, path in eggPaths: > srcIdx = path.rfind('src') > if srcIdx == -1: > # this is an egg package, strip down base path > basePath = path > moduleNames = pkgName.split('.') > moduleNames.reverse() > for mName in moduleNames: > mIdx = path.rfind(mName) > basePath = basePath[:mIdx] > pkgPath = path[len(basePath):] > else: > # this is a package linked in as externals > basePath = path[:srcIdx] > pkgPath = path[len(basePath):] > > I don't understand why we need different code for "packages > linked in as externals". The "egg package" code works > actually better for linked in packages that don't follow the > 'src' convention. > > Proposal: Use the 'if' code for all packages. I was fighting several times with this part during coding. The only thing which this part has to make sure is that we do not use anything outside of the package in our path. The reason for not including everything outside the package in our path is that such a path whould be depend on the local setup e.g. D:\foo\dev\zope\session:3 We only have to make sure that this never will happen and that we for each use case generate path like: zope/session.py:3 It could be that the if part is working for all usecases. but I'n not sure without debugging. > 5. writing makers > - > > I'd like to specify additional makers. This is a nice hook, > but why are only these three arguments passed to custom poMakers? > > maker.add(poMaker(path, basePath, exclude_dirs), > basePath) > > I miss 'domain' and 'include_default_domain'. > > Proposal: Pass in the additional arguments and fall back to > the old signature for BBB. > > > Does all that make sense? Any objections or better ideas? > > Should changes for POTMaker go into zope.app.locales.extract > or should > z3c.recipe.i18n use a customized version? I think it's probably the best idea to enhance the method signature in zope.app.locales.extract if this is possible without to break compatibiliy. Yes, everything makes sense to me. Thanks a lot yuppie, this are very good improvments for z3c.recipe.i18n Regards Roger Ineichen ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi! I plan to use z3c.recipe.i18n for some Zope 2 CMF products. But to get things working I did have to modify z3c.recipe.i18n a bit. It would be nice if I could get some feedback regarding the issues I found: 1.) running tests - test.py tries to install 'zodbcode' and 'zope.app.interface'. That doesn't work for me. AFAICS those two eggs are no longer indirect testing dependencies. After removing those two lines all tests pass. Proposal: Remove those two lines in test.py. 2.) looking up the product version -- POTMaker._getProductVersion() doesn't work for me. zope.app.applicationcontrol is not used by Zope 2 and is not part of the specified dependencies. This raises an error. Proposal: Catch the error. Return an empty string if version is not found. 3.) customizing the .pot header --- POTMaker.write() uses a harcoded Zope 3 specific pot_header template. Proposal: The easiest and most flexible way to customize this seems to be an option that allows to specify a file that contains the pot_header template. 4.) looking up basePath --- i18nextract.main() contains these lines: # add maker for each given path for pkgName, path in eggPaths: srcIdx = path.rfind('src') if srcIdx == -1: # this is an egg package, strip down base path basePath = path moduleNames = pkgName.split('.') moduleNames.reverse() for mName in moduleNames: mIdx = path.rfind(mName) basePath = basePath[:mIdx] pkgPath = path[len(basePath):] else: # this is a package linked in as externals basePath = path[:srcIdx] pkgPath = path[len(basePath):] I don't understand why we need different code for "packages linked in as externals". The "egg package" code works actually better for linked in packages that don't follow the 'src' convention. Proposal: Use the 'if' code for all packages. 5. writing makers - I'd like to specify additional makers. This is a nice hook, but why are only these three arguments passed to custom poMakers? maker.add(poMaker(path, basePath, exclude_dirs), basePath) I miss 'domain' and 'include_default_domain'. Proposal: Pass in the additional arguments and fall back to the old signature for BBB. Does all that make sense? Any objections or better ideas? Should changes for POTMaker go into zope.app.locales.extract or should z3c.recipe.i18n use a customized version? Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Am 15.05.2009 um 12:36 schrieb Christian Zagrodnick: [...] > Okay, would you give me the pypi access (user zagy)? Done. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Am 15.05.2009 um 11:40 schrieb Christian Zagrodnick: > Hi, > > the tests of z3c.reipce.i18n break on unix systems, for instance with: > > Failed example: >ls('bin') > Expected: >- buildout-script.py >- buildout.exe >- i18ncompile-script.py >- i18ncompile.exe >- i18nextract-script.py >- i18nextract.exe >- i18nmergeall-script.py >- i18nmergeall.exe >- i18nstats-script.py >- i18nstats.exe > Got: >- buildout >- i18ncompile >- i18nextract >- i18nmergeall >- i18nstats > > > What's the general way of testing those things in both environments? I > don't have a windows box to test this. I also see most recipes are > tested only for unix (which would be fine for me). In z3c.recipe.paster I solved this with two re normalizers, see http://tinyurl.com/ofc6nx lines 115 and 116. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
On 2009-05-15 12:16:30 +0200, "Roger Ineichen" said: > Hi Christian > >> What's the general way of testing those things in both > >> environments? I don't have a windows box to test this. I also > >> see most recipes are tested only for unix (which would be > >> fine for me). >> > >> How should we proceed in this special case? Actually there is > >> a bug which I'm going to fix w/o having passing tests now. > > I'm fine if you switch the tests that they pass on linux and > will break on windows. I can catchup the tests later and try > to make them running again on windows and linux. Okay, would you give me the pypi access (user zagy)? > > Thanks a lot for help improve missing parts or fix issues! np, after all I want to use it :) -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.recipe.i18n tests break on unix
Hi Christian > Betreff: [Zope-dev] z3c.recipe.i18n tests break on unix > > Hi, > > the tests of z3c.reipce.i18n break on unix systems, for instance with: > > Failed example: > ls('bin') > Expected: > - buildout-script.py > - buildout.exe > - i18ncompile-script.py > - i18ncompile.exe > - i18nextract-script.py > - i18nextract.exe > - i18nmergeall-script.py > - i18nmergeall.exe > - i18nstats-script.py > - i18nstats.exe > Got: > - buildout > - i18ncompile > - i18nextract > - i18nmergeall > - i18nstats > > > What's the general way of testing those things in both > environments? I don't have a windows box to test this. I also > see most recipes are tested only for unix (which would be > fine for me). > > How should we proceed in this special case? Actually there is > a bug which I'm going to fix w/o having passing tests now. I'm fine if you switch the tests that they pass on linux and will break on windows. I can catchup the tests later and try to make them running again on windows and linux. Thanks a lot for help improve missing parts or fix issues! Regards Roger Ineichen > Regards, > -- > Christian Zagrodnick · c...@gocept.com > gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) > · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 > 345 1229889 1 Zope and Plone consulting and development > > > ___ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] z3c.recipe.i18n tests break on unix
Hi, the tests of z3c.reipce.i18n break on unix systems, for instance with: Failed example: ls('bin') Expected: - buildout-script.py - buildout.exe - i18ncompile-script.py - i18ncompile.exe - i18nextract-script.py - i18nextract.exe - i18nmergeall-script.py - i18nmergeall.exe - i18nstats-script.py - i18nstats.exe Got: - buildout - i18ncompile - i18nextract - i18nmergeall - i18nstats What's the general way of testing those things in both environments? I don't have a windows box to test this. I also see most recipes are tested only for unix (which would be fine for me). How should we proceed in this special case? Actually there is a bug which I'm going to fix w/o having passing tests now. Regards, -- Christian Zagrodnick · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )