pinning version of zc.buildout useless?

View: New views
6 Messages — Rating Filter:   Alert me  

pinning version of zc.buildout useless?

by Vincent Fretin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

When you create a grok project with grokproject 0.8, you have the
versions.cfg file in the created directory.
In this file you have zc.buildout version pinned to 1.0.6.
For me this version will never be satisfied because when you execute
`python2.4 bootstrap.py`, it installs always the latest version on
PYPI (now it's 1.1.1). Am I wrong?
It says "Getting distribution for 'zc.buildout==1.0.6'", but actually
it copy the one installed system-wide (or in a virtualenv I think) or
download the latest from pypi.
The generated bin/buildout use zc.buildout 1.1.1.

The only way to actually use a specific version of zc.buildout is to
install it system-wide (or in a virtualenv) with
easy_install-2.4 zc.buildout==1.0.6
and then use
buildout bootstrap

Regards
--
Vincent Fretin
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Re: pinning version of zc.buildout useless?

by Maurits van Rees-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Vincent Fretin, on 2008-07-30:

> Hi,
>
> When you create a grok project with grokproject 0.8, you have the
> versions.cfg file in the created directory.
> In this file you have zc.buildout version pinned to 1.0.6.
> For me this version will never be satisfied because when you execute
> `python2.4 bootstrap.py`, it installs always the latest version on
> PYPI (now it's 1.1.1). Am I wrong?
> It says "Getting distribution for 'zc.buildout==1.0.6'", but actually
> it copy the one installed system-wide (or in a virtualenv I think) or
> download the latest from pypi.
> The generated bin/buildout use zc.buildout 1.1.1.

"python bootstrap.py" will give you the latest zc.buildout.  When you
then run bin/buildout, it should update itself to use the pinned
version from versions.cfg.  A bit unexpected perhaps, but that was
what happened last time I tried this.  

I don't know how a system-wide installed zc.buildout would affect
this.

--
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Re: Re: pinning version of zc.buildout useless?

by Vincent Fretin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wed, Jul 30, 2008 at 9:33 PM, Maurits van Rees
<m.van.rees@...> wrote:

> Vincent Fretin, on 2008-07-30:
>> Hi,
>>
>> When you create a grok project with grokproject 0.8, you have the
>> versions.cfg file in the created directory.
>> In this file you have zc.buildout version pinned to 1.0.6.
>> For me this version will never be satisfied because when you execute
>> `python2.4 bootstrap.py`, it installs always the latest version on
>> PYPI (now it's 1.1.1). Am I wrong?
>> It says "Getting distribution for 'zc.buildout==1.0.6'", but actually
>> it copy the one installed system-wide (or in a virtualenv I think) or
>> download the latest from pypi.
>> The generated bin/buildout use zc.buildout 1.1.1.
>
> "python bootstrap.py" will give you the latest zc.buildout.  When you
> then run bin/buildout, it should update itself to use the pinned
> version from versions.cfg.  A bit unexpected perhaps, but that was
> what happened last time I tried this.
I made further tests.
First I removed zc.buildout system-wide and all zc.buildout eggs in
/home/alvis/.buildout/eggs/
I ran python2.4 bootstrap.py, it says:
$ python2.4 bootstrap.py
Creating directory '/home/alvis/helloworld/bin'.
Creating directory '/home/alvis/helloworld/parts'.
Creating directory '/home/alvis/helloworld/develop-eggs'.
Generated script '/home/alvis/helloworld/bin/buildout'.
Develop: '/home/alvis/helloworld/.'
Develop: '/home/alvis/helloworld/.'
Installing eggbasket.
Installing eggbasket.
Getting distribution for 'zc.buildout==1.0.6'.
Getting distribution for 'zc.buildout==1.0.6'.
Got zc.buildout 1.0.6.
Got zc.buildout 1.0.6.

By the way, why all messages after bin/buildout is generated are printed twice?

Finally I have 1.0.6 and 1.1.1 zc.buildout eggs in my
/home/alvis/.buildout/eggs/ directory

and in bin/buildout, it uses 1.1.1. For me zc.buildout 1.1.1 is
installed because of ws.require('zc.buildout') line in bootstrap.py.
Then when it calls "zc.buildout.buildout.main(sys.argv[1:] +
['install', 'eggbasket'])", it generate first the bin/buildout script
and then install zc.buildout 1.0.6.

But in bin/buildout, you have always the 1.1.1 version, so it's this
version which is used. right?

When you run bin/buildout after, it don't regenerate the bin/buildout
file to use 1.0.6:
alvis@yusuke:~/vrepoze/helloworld$ bin/buildout
Develop: '/home/alvis/helloworld/.'
Updating eggbasket.
Installing app.
Generated script '/home/alvis/helloworld/parts/app/runzope'.
Generated script '/home/alvis/helloworld/parts/app/debugzope'.
Installing data.
Installing zopectl.
Generated script '/home/alvis/helloworld/bin/zopectl'.
Installing i18n.
i18n: setting up i18n tools
Generated script 'bin/i18nextract'.
Generated script 'bin/i18nmergeall'.
Generated script 'bin/i18nstats'.
Installing test.
Generated script '/home/alvis/helloworld/bin/test'.

At this point bin/buildout use always 1.1.1.

--
Vincent Fretin
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Re: pinning version of zc.buildout useless?

by Maurits van Rees-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Vincent Fretin, on 2008-07-31:

> On Wed, Jul 30, 2008 at 9:33 PM, Maurits van Rees
> I made further tests.
> First I removed zc.buildout system-wide and all zc.buildout eggs in
> /home/alvis/.buildout/eggs/
> I ran python2.4 bootstrap.py, it says:
> $ python2.4 bootstrap.py
> Creating directory '/home/alvis/helloworld/bin'.
> Creating directory '/home/alvis/helloworld/parts'.
> Creating directory '/home/alvis/helloworld/develop-eggs'.
> Generated script '/home/alvis/helloworld/bin/buildout'.
> Develop: '/home/alvis/helloworld/.'
> Develop: '/home/alvis/helloworld/.'
> Installing eggbasket.
> Installing eggbasket.
> Getting distribution for 'zc.buildout==1.0.6'.
> Getting distribution for 'zc.buildout==1.0.6'.
> Got zc.buildout 1.0.6.
> Got zc.buildout 1.0.6.
>
> By the way, why all messages after bin/buildout is generated are printed twice?

Known bug.  I thought is was in the launchpad tracker but I cannot
find it there.
https://bugs.launchpad.net/zc.buildout/+bugs

> Finally I have 1.0.6 and 1.1.1 zc.buildout eggs in my
> /home/alvis/.buildout/eggs/ directory
>
> and in bin/buildout, it uses 1.1.1. For me zc.buildout 1.1.1 is
> installed because of ws.require('zc.buildout') line in bootstrap.py.

Correct.

> Then when it calls "zc.buildout.buildout.main(sys.argv[1:] +
> ['install', 'eggbasket'])", it generate first the bin/buildout script
> and then install zc.buildout 1.0.6.

Correct.

> But in bin/buildout, you have always the 1.1.1 version, so it's this
> version which is used. right?
>
> When you run bin/buildout after, it don't regenerate the bin/buildout
> file to use 1.0.6:

For me this *does* happen, both on my laptop with a global zc.buildout
installed and on my desktop without a global zc.buildout install.

====================================================
maurits@hobb:~/buildout/foo $ cat bin/buildout
#!/usr/bin/python2.4

import sys
sys.path[0:0] = [
  '/home/maurits/buildout-eggs/setuptools-0.6c8-py2.4.egg',
  '/home/maurits/buildout-eggs/zc.buildout-1.1.1-py2.4.egg',
  ]

import zc.buildout.buildout

if __name__ == '__main__':
    zc.buildout.buildout.main()
maurits@hobb:~/buildout/foo $ bin/buildout -nv
Installing 'zc.buildout', 'setuptools'.
We have the distribution that satisfies 'zc.buildout==1.0.6'.
We have the best distribution that satisfies 'setuptools'.
Picked: setuptools = 0.6c8
Upgraded:
  zc.buildout version 1.0.6;
restarting.
Generated script '/home/maurits/buildout/foo/bin/buildout'.
Installing 'zc.buildout', 'setuptools'.
====================================================

Notice the lines stating 'Upgraded' and 'restarting'.

It could be that this only ever happens when you explicitly tell
buildout to run in newest mode with "bin/buildout -n".  Indeed when
you already have version x for a package and versions.cfg specifies
version y then version x will keep being used unless you run with '-n'
(or have newest = true in buildout.cfg).

But then I do not understand why you would get a download for both
1.1.1 and 1.0.6.

--
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Re: Re: pinning version of zc.buildout useless?

by Vincent Fretin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Tue, Aug 5, 2008 at 10:57 PM, Maurits van Rees
<m.van.rees@...> wrote:

> For me this *does* happen, both on my laptop with a global zc.buildout
> installed and on my desktop without a global zc.buildout install.
>
> ====================================================
> maurits@hobb:~/buildout/foo $ cat bin/buildout
> #!/usr/bin/python2.4
>
> import sys
> sys.path[0:0] = [
>  '/home/maurits/buildout-eggs/setuptools-0.6c8-py2.4.egg',
>  '/home/maurits/buildout-eggs/zc.buildout-1.1.1-py2.4.egg',
>  ]
>
> import zc.buildout.buildout
>
> if __name__ == '__main__':
>    zc.buildout.buildout.main()
> maurits@hobb:~/buildout/foo $ bin/buildout -nv
> Installing 'zc.buildout', 'setuptools'.
> We have the distribution that satisfies 'zc.buildout==1.0.6'.
> We have the best distribution that satisfies 'setuptools'.
> Picked: setuptools = 0.6c8
> Upgraded:
>  zc.buildout version 1.0.6;
> restarting.
> Generated script '/home/maurits/buildout/foo/bin/buildout'.
> Installing 'zc.buildout', 'setuptools'.
> ====================================================
>
> Notice the lines stating 'Upgraded' and 'restarting'.
>
> It could be that this only ever happens when you explicitly tell
> buildout to run in newest mode with "bin/buildout -n".  Indeed when
> you already have version x for a package and versions.cfg specifies
> version y then version x will keep being used unless you run with '-n'
> (or have newest = true in buildout.cfg).
You're absolutely right. zc.buildout is downgraded only in newest mode.
By default in a new grokproject you have newest=false in buildout.cfg,
so when you execute only "bin/buildout", zc.buildout is not
downgraded.

>
> But then I do not understand why you would get a download for both
> 1.1.1 and 1.0.6.
I don't know how all the zc.buildout machinery works, but it downloads
and installs both version in non-newest mode.
Actually, the bootstrap.py script download 1.1.1 and then zc.buildout
download the pinned version.
And only in newest mode it regenerates the bin/buildout script with
the pinned version.

--
Vincent Fretin
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Re: pinning version of zc.buildout useless?

by Maurits van Rees-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Vincent Fretin, on 2008-08-06:
> I don't know how all the zc.buildout machinery works, but it downloads
> and installs both version in non-newest mode.
> Actually, the bootstrap.py script download 1.1.1 and then zc.buildout
> download the pinned version.
> And only in newest mode it regenerates the bin/buildout script with
> the pinned version.

Ah, that (mostly) makes sense.

--
Maurits van Rees | http://maurits.vanrees.org/
            Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev