Well that was something new for me. Having two versions of the same package in the same buildout file. Actually I was installing a few distributions in my workplace. So some distros have version pinned in their setup.py install_requires section, and when I run the buildout expecting the versions to be printed, its not printing those alone. So mentioning the version was not in the buildout file originally, but I see your point of putting them in [versions] section. But tell me this. In the above example(pinning a version number in install_requires section of setup.py) expecting the version of the package to be printed is a valid usecase right ? Is it not ? I know from the example which you gave previously there seems to be some ambiguity from which version to pick if there are multiple versions. right ? Thats why its left out or ? Regards, Nandakishore On Wed, Aug 17, 2011 at 7:44 AM, Chris Withers wrote:

On 16/08/2011 18:31, B.Nanda Kishore wrote:

...

[buildout] index=http://localhost:8000/ parts = deps extensions = buildout-versions

[deps] recipe = zc.recipe.egg eggs = PkgA PkgB==0.1.0

When I ran the buildout, this is the output I got.

[versions] PkgA = 0.1.0 buildout-versions = 1.6 distribute = 0.6.19 zc.buildout = 1.5.2 zc.recipe.egg = 1.3.2

Notice that PkgB's version is not printed.

Yes, as I said before, this is intended and will not change.

Here's an example buildout.cfg that shows why:

[buildout] parts = part1 part2

extensions = buildout-versions versions = versions

[versions] SomePackage = 2.0

[part1]

recipe = zc.recipe.egg eggs = SomePackage

[part2]

recipe = zc.recipe.egg eggs = SomeOtherPackage SomePackage==1.0

To explain, SomeOtherPackage has a dependency on SomePackage, but hasn't been updated to work with version 2.0, so needs to be pinned to 1.0. However, the rest of the buildout is fine to use with the new version 2.0.

In general, buildout-versions should be used as described in its docs and versions should *only* be pinned in a [versions] section.

*Why* are you pinning in the eggs line?

cheers,

Chris

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

On 16/08/2011 20:32, B.Nanda Kishore wrote:

Actually I was installing a few distributions in my workplace. So some distros have version pinned in their setup.py install_requires section,

This is pretty evil. Why on earth are you doing this? You should only ever place version limits in install_requires, and even then, only if there are compatibility issues with a library a package depends on. eg: install_requries=['SomePackage < 2.0']

and when I run the buildout expecting the versions to be printed,

For the third time, why are you expecting versions to be printed here? You've pinned the version required, so buildout-versions won't report it as unpinned...

But tell me this. In the above example(pinning a version number in install_requires section of setup.py) expecting the version of the package to be printed is a valid usecase right ?

Wrong.

Is it not ?

No, it is not. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

On 17/08/2011 05:40, Fred Drake wrote:

On Tue, Aug 16, 2011 at 10:14 PM, Chris Withers wrote:

...

*Why* are you pinning in the eggs line?

At Zope, we've had to do this when different processes constructed by a build had to use different versions of libraries. buildout-versions aside, it's not that unusual a case.

Indeed, I believe I did explain that usecase ;-) Myself, I'd just use multiple buildouts, and I don't think I've ever bumped into the situation you're describing, but nonetheless, if you've pinned the version some other way, then buildout-versions won't tell you that it hasn't been pinned... cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk