buildout 1 still not managing to pin buildout to 1.x
Hi All,
So, having given up on buildout 2 for this package again (need for 2.5 support) I dutifully put in the bootstrap.py from buildout 1:
curl http://downloads.buildout.org/1/bootstrap.py > bootstrap.py
python2.5 on my mac didn't work, thanks to a broken system python, so on to 2.6, which appeared to go okay except:
buzzkill:checker chris$ bin/nosetests zc.buildout 2 needs distribute, not setuptools. Are you using an outdated bootstrap.py? Make sure you have the latest version downloaded from http://downloads.buildout.org/2/bootstrap.py
Great... Wonderful... I thought 1/bootstrap.py was supposed to pin to buildout 1 for you without the need for any other voodoo?
Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/10/2013 06:22 AM, Chris Withers wrote:
Hi All,
So, having given up on buildout 2 for this package again (need for 2.5 support) I dutifully put in the bootstrap.py from buildout 1:
curl http://downloads.buildout.org/1/bootstrap.py > bootstrap.py
python2.5 on my mac didn't work, thanks to a broken system python, so on to 2.6, which appeared to go okay except:
buzzkill:checker chris$ bin/nosetests zc.buildout 2 needs distribute, not setuptools. Are you using an outdated bootstrap.py? Make sure you have the latest version downloaded from http://downloads.buildout.org/2/bootstrap.py
Great... Wonderful... I thought 1/bootstrap.py was supposed to pin to buildout 1 for you without the need for any other voodoo?
Works for me:
$ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts =" > buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-%5C 0.6c11-py2.5.egg Creating directory '/tmp/withers/bin'. Creating directory '/tmp/withers/parts'. Creating directory '/tmp/withers/eggs'. Creating directory '/tmp/withers/develop-eggs'. Getting distribution for 'setuptools'. /opt/Python-2.5.5/lib/python2.5/distutils/dist.py:263: \ UserWarning: Unknown distribution option: 'src_root' warnings.warn(msg) Got setuptools 0.7.2. Generated script '/tmp/withers/bin/buildout'. $ bin/buildout $ ls eggs setuptools-0.7.2-py2.5.egg zc.buildout-1.7.1-py2.5.eg
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On 10/06/2013 18:57, Tres Seaver wrote:
Works for me:
$ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts ="> buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py
Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps.
There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened.
Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2013 05:27 AM, Chris Withers wrote:
On 10/06/2013 18:57, Tres Seaver wrote:
Works for me:
$ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts ="> buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py
Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps.
There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened.
That same recipe works with 2.7. In general, the presence of .installed.cfg should be thought of as problematic for any big surgery (like changing bootstraps, or major versions of buildout), because it hampers repeatability in order to make the build run faster.
When in doubt, remove .installed.cfg and re-run buildout after any such change.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tseaver@palladion.com wrote:
When in doubt, remove .installed.cfg and re-run buildout after any such change.
So the real question is: Why doesn't bootstrap.py just do this?
I've stumbled on this many times as well; I don't see an advantage to this not being handled by the bootstrap, because it will surprise us eventually.
Some of us (include me, apparently) are more easily surprised than others.
-Fred
On Tue, Jun 11, 2013 at 7:48 PM, Fred Drake fred@fdrake.net wrote:
On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tseaver@palladion.com wrote:
When in doubt, remove .installed.cfg and re-run buildout after any such change.
So the real question is: Why doesn't bootstrap.py just do this?
Because it's not just an optimization and removing .installed.cfg prevents cleanup that might be desirable. Removing it as part of bootstrap seems too magic for me.
I'd rather:
- Error if there's a .installed.cfg
- adding a --force option that tries to uninstall and then removed .instaled.cfg.
I've stumbled on this many times as well; I don't see an advantage to this not being handled by the bootstrap, because it will surprise us eventually.
It rarely surprises me.
Some of us (include me, apparently) are more easily surprised than others.
No kidding. ;)
Jim
On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver tseaver@palladion.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/11/2013 05:27 AM, Chris Withers wrote:
On 10/06/2013 18:57, Tres Seaver wrote:
Works for me:
$ mkdir /tmp/withers $ cd /tmp/withers $ echo "[buildout] parts ="> buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py ... $ /opt/Python-2.5.x/bin/python bootstrap.py
Try with 2.7, and also try going from 1 to 2 and back again by switching bootstraps.
There's likely something funky going on (.installed.cfg, develop-eggs or some other goat sacrifice in bin/) but it definitely happened.
That same recipe works with 2.7. In general, the presence of .installed.cfg should be thought of as problematic for any big surgery (like changing bootstraps, or major versions of buildout), because it hampers repeatability in order to make the build run faster.
No. It is not an optimization. It's there to know what needs to be uninstalled.
It's often OK to just remove it. but by doing so you're forgoing cleanup.
It would be better to uninstall everything with the old buildout:
bin/buildout buildout:parts=
Before removing the installed file.
Jim
participants (5)
-
Chris Withers -
Chris Withers -
Fred Drake -
Jim Fulton -
Tres Seaver