Hash: SHA1

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
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to