On Thu, Aug 22, 2013 at 09:07:52PM -0700, Benedek Zoltan wrote: > I've downloaded bootstrap.py and tried to initialize with system python: > > sabd1@sab /home/buildout $ wget > http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
FWIW that's an old version. You should be using one of wget http://downloads.buildout.org/1/bootstrap.py wget http://downloads.buildout.org/2/bootstrap.py to get a bootstrap for zc.buildout 1.7.x or 2.2, respectively. If you don't know which one you want, use 2. > sabd1@sab /home/buildout $ python bootstrap.py > Downloading > http://pypi.python.org/packages/2.7/s/setuptools/setuptools-0.6c11-py2.7.egg > > Traceback (most recent call last): > ... > pkg_resources.VersionConflict: (setuptools 0.6c11 > (/tmp/tmpzJN6Tt/setuptools-0.6c11-py2.7.egg), > Requirement.parse('setuptools>=0.7')) > > I know, it works with virtualenv, but with system python is this expected > behavior? Basically, yes. At least it's what I've come to expect. Here's my fool-proof method of setting up buildouts on the brave new post-setuptools-0.7 world: virtualenv python python/bin/pip install -U setuptools python/bin/python bootstrap.py bin/buildout You'll notice that I upgrade setuptools in the virtualenv I created. That's because I'm using python-virtualenv from Ubuntu, and it installs an old copy of distribute in the virtualenv by default. Then bootstrap tries to upgrade it to the newest distribute, which is a shim that depends on new setuptools, but bootstrap's upgrader isn't smart enough to go and fetch dependencies so it all breaks down in the same error you've seen. Upgrading setuptools with pip avoids this failure. Marius Gedminas -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald Knuth
signature.asc
Description: Digital signature
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
