-----BEGIN PGP SIGNED MESSAGE-----
Hanno Schlichting wrote:
> Tres Seaver wrote:
>> Andreas Jung wrote:
>>> Please look at the getPackages() method taking the version*cfg files
>>> into account. So all versions should be pinned. However there is
>>> obviously a difference between using buildout with pinned versions
>>> and setuptools or a small undetected hole in the process.
>> The issue must be that one of the "pinned" dependencies
>> (zope.publisher?) has an unpinned dependency (maybe transitively?) which
>> requires a newer version of zope.component.
> What I think is more likely to have happened here is:
> An additional package (like one under development) was installed first.
> This depends on some zope.foo package (maybe zope.publisher) which wants
> zope.component 3.6. setuptools goes and fetches the latest version of
> all of these. Now later on the Zope2 egg is put into the environment and
> requires zope.component 3.5.1 - result VersionConflict.
This error is reproducible in a fresh virtualenv.
> Setuptools loads packages and puts them into the environment as it finds
> them. It doesn't build a full tree of dependencies first. This is what
> pip adds for example.
Right: this is what I was calling the "incremental dependency
discovery" bit in setuptlools.
> Unless you have a KGS or any kind of version restrictions for everything
> from the start, you will always run into these problems. Managing exact
> versions inside setup.py doesn't work.
A Zope2-specific index supplies the same need.
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -