i ment on bootstrap .. python bootstrap.py -v1.4.3 2010/4/30 Rok Garbas <rok.garbas@gmail.com>:

run buildout with -v1.4.3 ... this fixed it for me.... after 1h ofcourse :P

2010/4/30 Chris McDonough <chrism@plope.com>:

...

I have a relatively simple buildout that is a directory which is also a virtualenv (the buildout directory was prepped after checkout with Python 2.4 "virtualenv --no-site-packages ." and the bootstrap was run using the resulting "bin/python").

Just now, I had to rerun bin/buildout in that existing directory, and I got this:

[chrism@thinko deformsite]$ bin/buildout Getting distribution for 'zc.buildout'. Got zc.buildout 1.5.0b1. Upgraded:  zc.buildout version 1.5.0b1; restarting. Generated script '/home/chrism/projects/deformsite/bin/buildout'. Develop: '/home/chrism/projects/deformsite/src/deformsite' Develop: '/home/chrism/projects/deformsite/src/deform' Develop: '/home/chrism/projects/deformsite/src/colander' Getting distribution for 'zc.recipe.egg'. Traceback (most recent call last):  File "<string>", line 1, in ?  File "/home/chrism/projects/deformsite/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg/setuptools/__init__.py", line 2, in ?    from setuptools.extension import Extension, Library  File "/home/chrism/projects/deformsite/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg/setuptools/extension.py", line 1, in ?    from distutils.core import Extension as _Extension  File "/home/chrism/projects/deformsite/lib/python2.4/distutils/__init__.py", line 3, in ?    import warnings ImportError: No module named warnings An error occured when trying to install zc.recipe.egg 1.2.3b1. Look above this message for any errors that were output by easy_install. While:  Installing.  Getting section deformsite.  Initializing section deformsite.  Installing recipe zc.recipe.egg.  Getting distribution for 'zc.recipe.egg'. Error: Couldn't install: zc.recipe.egg 1.2.3b1

I had built a new virtualenv'ed buildout only a few hours before it the new zc.buildout was released with the most recent releases of everything.  I had seen a new release of zc.buildout went up, so I figured I just needed to kinda start from scratch.  So subsequently I blew everything away and did what I usually do when I want to start over:

chrism@thinko projects]$ svn co $REPOZE_SVN/buildouts/deformsite <snip> Checked out revision 9276. [chrism@thinko projects]$ cd deformsite [chrism@thinko deformsite]$ virtualenv --no-site-packages . New python executable in ./bin/python Installing setuptools.............done. [chrism@thinko deformsite]$ bin/python bootstrap.py Creating directory '/home/chrism/projects/deformsite/parts'. Creating directory '/home/chrism/projects/deformsite/eggs'. Creating directory '/home/chrism/projects/deformsite/develop-eggs'. Getting distribution for 'setuptools'. Got setuptools 0.6c11.

But when I went to run it, I got this:

Generated script '/home/chrism/projects/deformsite/bin/buildout'. [chrism@thinko deformsite]$ bin/buildout Traceback (most recent call last):  File "bin/buildout", line 14, in ?    import site # imports custom buildout-generated site.py  File "/home/chrism/projects/deformsite/parts/buildout/site.py", line 661, in ?    main()  File "/home/chrism/projects/deformsite/parts/buildout/site.py", line 628, in main    virtual_install_main_packages()  File "/home/chrism/projects/deformsite/parts/buildout/site.py", line 546, in virtual_install_main_packages    f = open(os.path.join(os.path.dirname(__file__), 'orig-prefix.txt')) IOError: [Errno 2] No such file or directory: '/home/chrism/projects/deformsite/parts/buildout/orig-prefix.txt'

If you were paying attention, you'd notice that I made the buildout dir into a virtualenv above, which I've been doing for a long time now to get actual isolation.  So at that point, I tried to pin zc.buildout and zc.recipe.egg to an older version by adding the following to my buildout.cfg:

versions = versions [versions] zc.buildout = 1.4.3 zc.recipe.egg = 1.2.2

But when I then did the same dance that blew up above with the version pins, it now blew up differently:

[chrism@thinko projects]$ cd deformsite [chrism@thinko deformsite]$ virtualenv --no-site-packages . New python executable in ./bin/python Installing setuptools.............done. [chrism@thinko deformsite]$ bin/python bootstrap.py Creating directory '/home/chrism/projects/deformsite/parts'. Creating directory '/home/chrism/projects/deformsite/eggs'. Creating directory '/home/chrism/projects/deformsite/develop-eggs'. Getting distribution for 'setuptools'. Got setuptools 0.6c11. Getting distribution for 'zc.buildout==1.4.3'. Traceback (most recent call last):  File "<string>", line 1, in ?  File "/home/chrism/projects/deformsite/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg/setuptools/__init__.py", line 2, in ?    from setuptools.extension import Extension, Library  File "/home/chrism/projects/deformsite/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg/setuptools/extension.py", line 1, in ?    from distutils.core import Extension as _Extension  File "/home/chrism/projects/deformsite/lib/python2.4/distutils/__init__.py", line 3, in ?    import warnings ImportError: No module named warnings An error occured when trying to install zc.buildout 1.4.3. Look above this message for any errors that were output by easy_install. While:  Bootstrapping.  Getting distribution for 'zc.buildout==1.4.3'. Error: Couldn't install: zc.buildout 1.4.3

I pdb stepped through this, and it dies when it reexecutes Python via os.spawnle of sys.executable (not on the initial execution of "python bootstrap.py"):

[chrism@thinko deformsite]$ bin/python bootstrap.py

...

/home/chrism/projects/deformsite/bootstrap.py(44)?() -> assert os.spawnle( (Pdb) l  39  40     ws = pkg_resources.working_set  41  42     import pdb; pdb.set_trace()  43  44  -> assert os.spawnle(  45         os.P_WAIT, sys.executable, sys.executable,  46         '-c', cmd, '-mqNxd', tmpeggs, 'zc.buildout',  47         dict(os.environ,  48              PYTHONPATH=  49 (Pdb) p sys.executable, cmd, tmpeggs ('/home/chrism/projects/deformsite/bin/python', 'from setuptools.command.easy_install import main; main()', '/tmp/tmpEduLSX') (Pdb) p ws.find(pkg_resources.Requirement.parse('setuptools')).location '/home/chrism/projects/deformsite/lib/python2.4/site-packages/setuptools-0.6c11-py2.4.egg' (Pdb)

But sure enough, when I run it with a "real" Python instead of the virtualenv it works.

Likely, the recent developers buildout of don't use virtualenv, so they won't have seen this behavior.  I don't have the fortitude to debug buildout right now, and the isolation of a virtualenv keeps us sane. Ideally, I could change the buildout.cfg somehow to ignore the new buildout release entirely to get back to a state where buildout could be driven with a virtualenv-Python.  Any hints?

- C

_______________________________________________ Distutils-SIG maillist  -  Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig

-- Rok Garbas, Python.Zope.Plone consulting web: http://garbas.si phone(si): +386 70 707 300 phone(es): +34 68 941 79 62 email: rok@garbas.si

-- Rok Garbas, Python.Zope.Plone consulting web: http://garbas.si phone(si): +386 70 707 300 phone(es): +34 68 941 79 62 email: rok@garbas.si

On Fri, 2010-04-30 at 08:57 +0200, Rok Garbas wrote:

i ment on bootstrap ..

python bootstrap.py -v1.4.3

Thanks Rok. With that hint, I was able to work around it in a virtualenv by: - Using the bootstrap.py from the 1.4.3 tag (<http://svn.zope.org/zc.buildout/tags/1.4.3/bootstrap/bootstrap.py?rev=106409&view=markup>) - Adding the [versions] stanza that pins zc.buildout 1.4.3 and zc.recipe.egg 1.2.2 to my buildout.cfg ala: versions = versions [versions] zc.buildout = 1.4.3 zc.recipe.egg = 1.2.2 - Running the above bootstrap.py with the virtualenv python and the -v1.4.3 argument. bin/python bootstrap.py -v1.4.3 - Run bin/buildout That produces a working environment. - C

Le 30/04/2010 09:33, Rok Garbas a écrit :

2010/4/30 Chris McDonough<chrism@plope.com>:

...

On Fri, 2010-04-30 at 08:57 +0200, Rok Garbas wrote:

...

i ment on bootstrap ..

python bootstrap.py -v1.4.3

oh .. right .. i had pinned zc.buildout as well. i was already thinking to start everything to do by hand ... yeah right ... then i woke up :)

Test with distribute support (with a recent boostrap.py file (svn.zope.org)): python bootstrap.py -d -- Cordialement, kiorky GPG Fingerprint:

Op 30-04-10 16:32, Gary Poster schreef:

On Apr 30, 2010, at 3:25 AM, Chris McDonough wrote:

...

- Running the above bootstrap.py with the virtualenv python and the -v1.4.3 argument.

bin/python bootstrap.py -v1.4.3

- Run bin/buildout

That produces a working environment.

Thanks for the clear instructions for the work-around, Chris and Rok.

While one of the goals of the new buildout is to make virtualenv unnecessary with it if desired, I think it is a priority that virtualenv and zc.buildout continue to be able to work together. I'll investigate this report today.

For the record, I see the same thing. I'll post some observations here in case they help in debugging. I have a python in a virtualenv and that one is on the PATH so it gets used by default. It gives the same problems the others were seeing. Using the system python (Mac 10.6 btw) works. "python bootstrap.py -v 1.4.3" solves it for me as well, as long as zc.buildout is properly pinned in the buildout.cfg, otherwise the next bin/buildout run will upgrade itself (when in newest mode), restart and give the same problems. So a buildout.cfg like this normally works: ===================== [buildout] versions = versions parts = somepart [versions] zc.buildout = 1.4.3 [somepart] recipe = zc.recipe.egg eggs = eolfixer ===================== Sometimes it still goes wrong though, depending on what I tweak in the versions, and whether I run buildout in newest or non-newest mode, and how bootstrap has been run. Sometimes I end up with this in bin/buildout, and then only a new bootstrap with -v1.4.3 helps: =================================================== #!/Users/mauritsvanrees/envs/py24/bin/python2.4 -S import sys sys.path[0:0] = [ '/Users/mauritsvanrees/tmp/foo/parts/buildout', ] ... =================================================== Cheers, Maurits

Hi Gary, Gary Poster wrote:

1. virtualenv fixes the -S flag. I doubt the virtualenv maintainers care, but if they did, that would be great.

Ian can correct if I'm wrong, but AFAIK that would be quite difficult. Virtualenv is built around a custom site.py; that's where all the magic happens. Without site.py all you've got is a relocated Python binary with a bare-bones mini-stdlib. You could place a complete copy of the stdlib inside each virtualenv; I think any other solution would involve re-creating virtualenv from the ground up. There are some interesting alternative approaches for doing virtualenvs, such as http://github.com/kvbik/rvirtualenv/; but that one also depends on site.py. I'm not aware of any that don't.

2. zc.buildout and bootstrap special case virtualenv: if virtualenv is sniffed (handwave...), we don't use -S. This is messy, but it means that virtualenv users get what they want without fuss, and non-virtualenv users can use a system Python without fuss.

FWIW, sniffing for virtualenv is quite easy (no hand-waving required!) Just check for hasattr(sys, 'real_prefix'). Pip uses this, so it's already depended on outside virtualenv. Carl