I had the same problem. I could not verify, that setuptools gets installed if not already in site-packages, but otherwise I have the same results as andi (see below). Whenever site-packages, was not listed in sys.path, a local setuptools egg was listed instead.
For me, it would feel most natural, if the system-wide site-packages would come after all the paths that point to components installed by the buildout, which probably means it should not be listed at all in the assignment to sys.path[0:0], as it is anyway listed further down the list. The behaviour for setuptools installed as egg, is exactly what I would expect.
The way bootstrap and buildout detect setuptools seems to differ, as can be seen, when setuptools is installed both as egg and as package. As I see it, it would be nicest to fix both, bootstrap, and buildout, to ...
... either move the position of site-packages in sys.path to the end of the sys.path[0:0] assignment (I did manually, and it solves the problem)
... or to never use setuptools installed system-wide, be it an egg or a package
I think the first would be cleanest and further, no local setuptools egg should be installed, if there is a system-wide one, that could be used instead (given its not out-dated or something). I hope there is no voodoo going on in setuptools, which prevents that solution.
I had the same problem. I could not verify, that setuptools gets installed if not already in site-packages, but otherwise I have the same results as andi (see below). Whenever site-packages, was not listed in sys.path, a local setuptools egg was listed instead.
For me, it would feel most natural, if the system-wide site-packages would come after all the paths that point to components installed by the buildout, which probably means it should not be listed at all in the assignment to sys.path[0:0], as it is anyway listed further down the list. The behaviour for setuptools installed as egg, is exactly what I would expect.
The way bootstrap and buildout detect setuptools seems to differ, as can be seen, when setuptools is installed both as egg and as package. As I see it, it would be nicest to fix both, bootstrap, and buildout, to ...
... either move the position of site-packages in sys.path to the end of the sys.path[0:0] assignment (I did manually, and it solves the problem)
... or to never use setuptools installed system-wide, be it an egg or a package
I think the first would be cleanest and further, no local setuptools egg should be installed, if there is a system-wide one, that could be used instead (given its not out-dated or something). I hope there is no voodoo going on in setuptools, which prevents that solution.
best regards
florian
<testing>
setuptools installed as package:
$ grep -C2 site-packages bin/buildout lib64/python2. 4/site- packages' , lib64/python2. 4/site- packages' , lib64/python2. 4/site- packages' , lib64/python2. 4/site- packages' , flo/eestec_ ploneldap/ eggs/zc. buildout- 1.0.0b31- py2.4.egg' , flo/eestec_ ploneldap/ eggs/plone. recipe. zope2instance- 0.9-py2. 4.egg', flo/eestec_ ploneldap/ eggs/zc. recipe. egg-1.0. 0-py2.4. egg', lib64/python2. 4/site- packages' , flo/eestec_ ploneldap/ eggs/zc. buildout- 1.0.0b31- py2.4.egg' , flo/eestec_ ploneldap/ eggs/python_ openid- 2.0.1-py2. 4.egg', flo/eestec_ ploneldap/ eggs/five. customerize- 0.2-py2. 4.egg', flo/eestec_ ploneldap/ eggs/five. localsitemanage r-0.2-py2. 4.egg', lib64/python2. 4/site- packages' , flo/eestec_ ploneldap/ eggs/python_ openid- 2.0.1-py2. 4.egg', flo/eestec_ ploneldap/ eggs/five. customerize- 0.2-py2. 4.egg', flo/eestec_ ploneldap/ eggs/five. localsitemanage r-0.2-py2. 4.egg', lib64/python2. 4/site- packages' , flo/eestec_ ploneldap/ eggs/python_ openid- 2.0.1-py2. 4.egg', lib64/zope- 2.10.4/ lib/python' ,
import sys
sys.path[0:0] = [
'/usr/
'/usr/
'/usr/
'/usr/
'/home/
]
$
$ grep -C2 site-packages bin/instance
'/home/
'/home/
'/usr/
'/home/
'/home/
--
'/home/
'/home/
'/usr/
'/home/
]
$
$ grep -C2 site-packages bin/zopepy
'/home/
'/home/
'/usr/
'/home/
'/usr/
$
site-packages occurs in sys.path of buildout, instance and zopepy.
No setuptools installed:
$ python bootstrap.py
Traceback (most recent call last):
File "bootstrap.py", line 46, in ?
PYTHONPATH=
AttributeError: 'NoneType' object has no attribute 'location'
$
setuptools installed as package + setuptools as egg.
$ python bootstrap.py flo/eestec_ ploneldap/ bin/buildout' .
Generated script '/home/
$ grep -C2 site-packages bin/buildout
$
Looks good so far. However:
$ ./bin/buildout -No flo/eestec_ ploneldap/ bin/zopepy' . flo/eestec_ ploneldap/ eggs/five. customerize- 0.2-py2. 4.egg', flo/eestec_ ploneldap/ eggs/five. localsitemanage r-0.2-py2. 4.egg', lib64/python2. 4/site- packages' , flo/eestec_ ploneldap/ eggs/python_ openid- 2.0.1-py2. 4.egg', lib64/zope- 2.10.4/ lib/python' ,
Uninstalling zopepy.
Uninstalling instance.
Uninstalling productdistros.
Uninstalling plone.
Installing plone.
Installing productdistros.
Installing instance.
Installing zopepy.
Generated interpreter '/home/
$
$ grep -C2 site-packages bin/zopepy
'/home/
'/home/
'/usr/
'/home/
'/usr/
$
site-packages are still listed in zopepy. It is written, that it got generated
again. However, I did a diff: it is exactly the same as before.
setuptools installed only as egg (no setuptools as package anymore):
$ python bootstrap.py
$
As expected, the buildout script didnt get changed.
$ ./bin/buildout -No flo/eestec_ ploneldap/ bin/instance' . flo/eestec_ ploneldap/ bin/zopepy' .
Updating plone.
Updating productdistros.
Updating instance.
Generated script '/home/
Updating zopepy.
Generated interpreter '/home/
$
$ grep -C2 site-packages bin/zopepy
$ grep -C2 site-packages bin/instance
$
site-packages is not listed anymore in sys.path, neither in zopepy nor in instance.
</testing>