Problems with buildout and zope.interface
Hi there! I am trying right now to convince people to use buildout and ZCA for the Open Grid Protocol project but it turns out that it's not working as expected. So maybe somebody on here can help me :-) The setup is Mac OSX 10.5.4 with Python 2.5.1 installed and apparently a zope.interface egg inside the standard install of Python of version 3.3.0. (you can see the contents of the lib dir her: http://pastebin.com/d3f5fb455) On some machines it now seems that this version is used instead of using a newer one the system wide installed one is used (for some reason not on my own machine), so the for instance the testrunner script looks like this: http://pastebin.com/d1a1024d2 (as you can see the standard lib is put into the path but not a separate zope.interface egg). The problem it comes down to when running buildout is the following: http://pastebin.com/d1ec846fa The important lines are probably: # File "/Users/tess/pyogp/eggs/zope.security-3.5.1-py2.5-macosx-10.5-i386.egg/zope/security/interfaces.py", line 20, in <module> # from zope.interface.common.interfaces import IException, IAttributeError # File "/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/zope/interface/common/interfaces.py", line 80, in <module> # classImplements(OverflowWarning, IOverflowWarning) # ZopeXMLConfigurationError: File "/Users/tess/pyogp/src/pyogp.lib.base/pyogp/lib/base/configure.zcml", line 6.2-6.55 # ZopeXMLConfigurationError: File "/Users/tess/pyogp/eggs/zope.component-3.4.0-py2.5.egg/zope/component/meta.zcml", line 7.4-11.10 # NameError: name 'OverflowWarning' is not defined So zope.component 3.4.0 probably needs zope.interface 3.4.x but installed is 3.3.0. Now my question is: How can I solve this problem. I think I tried to put zope.interface>=3.4 into all sorts of places but one outcomes only seemed to be a version conflict saying that 3.3.0 is installed already (unfortunately I also cannot test this myself as in my case it's working). Here is the buildout.cfg: http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev_ma... There also is a setup.py which contains the following dependencies: install_requires=[ 'setuptools', # -*- Extra requirements: -*- 'zope.interface>=3.4', 'zope.component [zcml]', 'WebOb', 'wsgiref', 'grokcore.component', ], (http://svn.secondlife.com/svn/linden/projects/2008/pyogp/pyogp.lib.base/trun...) And you can find the whole buildout here: http://svn.secondlife.com/svn/linden/projects/2008/pyogp/buildouts/libdev_ma... (this is a special version which only runs with Python2.5 and installed a development version of setuptools which I bundled with it because of the problems with subversion 1.5. I suspect though that it also fixed some other bugs as people here constantly seemed to have problems with buildout which now seems to be reason enough to move away from buildout and the Zope Component Architecture). Hope somebody can help :-) Thanks! Christian -- Christian Scholz video blog: http://comlounge.tv COM.lounge blog: http://mrtopf.de/blog Luetticher Strasse 10 Skype: HerrTopf 52064 Aachen Homepage: http://comlounge.net Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
Christian Scholz writes:
I am trying right now to convince people to use buildout and ZCA for the Open Grid Protocol project but it turns out that it's not working as expected. So maybe somebody on here can help me :-)
The setup is Mac OSX 10.5.4 with Python 2.5.1 installed and apparently a zope.interface egg inside the standard install of Python of version 3.3.0. (you can see the contents of the lib dir her: http://pastebin.com/d3f5fb455)
On some machines it now seems that this version is used instead of using a newer one the system wide installed one is used (for some reason not on my own machine), so the for instance the testrunner script looks like this: http://pastebin.com/d1a1024d2
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py -- Daniel Nouri http://danielnouri.org
Daniel Nouri wrote:
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py
Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout). So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part? -- Christian -- Christian Scholz video blog: http://comlounge.tv COM.lounge blog: http://mrtopf.de/blog Luetticher Strasse 10 Skype: HerrTopf 52064 Aachen Homepage: http://comlounge.net Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
Christian Scholz wrote:
Daniel Nouri wrote:
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py
Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout).
So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part?
Use a clean custom built Python. Regards, Baiju M
Baiju M wrote:
Christian Scholz wrote:
Daniel Nouri wrote:
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py
Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout).
So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part?
Use a clean custom built Python.
I myself am using this but the opinion of the rest of the group is that it should be as easy as possible to get going without the need to compile custom Pythons etc. I actually second this because losing potential co-developers directly at the beginning would be bad. (I think this is also one the ideas behind buildout: To make setting these things up as easy as possible). So maybe there is a way to solve this :) -- Christian -- Christian Scholz video blog: http://comlounge.tv COM.lounge blog: http://mrtopf.de/blog Luetticher Strasse 10 Skype: HerrTopf 52064 Aachen Homepage: http://comlounge.net Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
Christian Scholz:
Daniel Nouri wrote:
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py
Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout).
So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part?
This shell script should help: #!/bin/sh sudo easy_install virtualenv virtualenv . --no-site-packages bin/python bootstrap.py -- Daniel Nouri http://danielnouri.org
Daniel Nouri wrote:
Christian Scholz:
Daniel Nouri wrote:
The solution to this one is quite simple: Use virtualenv with --no-site-packages and then use bin/python to run bootstrap.py Ok, thanks. How do I deploy such a thing? I guess virtualenv then has to run by the one setting up his development sandbox? What files can/need to be in subversion? (I never used virtualenv before, only buildout).
So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part?
This shell script should help:
#!/bin/sh sudo easy_install virtualenv virtualenv . --no-site-packages bin/python bootstrap.py
Ok, except that this does not run under windows and it still needs to have easy_install installed. But if there is no existing script, maybe I write one then. I have my custom bootstrap for using the development version of setuptools now already anway. Thanks so far! -- Christian -- Christian Scholz video blog: http://comlounge.tv COM.lounge blog: http://mrtopf.de/blog Luetticher Strasse 10 Skype: HerrTopf 52064 Aachen Homepage: http://comlounge.net Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neue Show: TOPFtäglich (http://mrtopf.de/blog/category/topf-taglich/)
Christian Scholz wrote:
Ok, except that this does not run under windows and it still needs to have easy_install installed. But if there is no existing script, maybe I write one then. I have my custom bootstrap for using the development version of setuptools now already anway.
Ignas may have a customer bootstrap.py that helps even further over on the SchoolTool project... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Fri, Jul 25, 2008 at 02:53:55PM +0200, Christian Scholz wrote:
So my main question is probably: Is there a way to automate the process of installing and running virtualenv similar to what bootstrap.py does for buildout so that people do not need to care about the virtualenv part?
Yes, you can write a custom virtualenv bootstrap script as documented here: http://pypi.python.org/pypi/virtualenv#creating-your-own-bootstrap-scripts You can then distribute just your bootstrap script, and all somebody has to do is download and run it (assuming they have python). The bootstrapper will then fetch and run virtualenv, install easy_install into the virtualenv, and do anything else you put in your bootstrapper. Personally I've never tried combining virtualenv and buildout. -- Paul Winkler http://www.slinkp.com
participants (5)
-
Baiju M -
Chris Withers -
Christian Scholz -
Daniel Nouri -
Paul Winkler