buildout 1 still not managing to pin buildout to 1.x

[Chris Withers]

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

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk

[Tres Seaver]

-----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-\
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 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG2E3oACgkQ+gerLs4ltQ4n0ACgnIJb6c4Wf/3i+sY57FY1BRGa
emgAoJdTohJwbWmhGCvhzt/Pbv9AJTGT
=Bn58
-----END PGP SIGNATURE-----

[Fred Drake]

On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver <tse...@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

--
Fred L. Drake, Jr. <fred at fdrake.net>
"A storm broke loose in my mind." --Albert Einstein

[Jim Fulton]

On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver <tse...@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

--
Jim Fulton
http://www.linkedin.com/in/jimfulton

[Jim Fulton]

On Tue, Jun 11, 2013 at 7:48 PM, Fred Drake <fr...@fdrake.net> wrote:
> On Tue, Jun 11, 2013 at 7:22 PM, Tres Seaver <tse...@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. ;)