-----BEGIN PGP SIGNED MESSAGE-----
Andreas Jung wrote:
> On 16.03.2009 4:52 Uhr, Tres Seaver wrote:
>> Andreas Jung wrote:
>>> On 15.03.2009 18:42 Uhr, Tres Seaver wrote:
>>>> -------- Original Message --------
>>>> Subject: [Bug 343079] [NEW] Broken distribution (2009-03-15)
>>>> Date: Sun, 15 Mar 2009 07:42:00 -0000
>>>> From: dmaurer <die...@handshake.de>
>>>> Reply-To: Bug 343079 <343...@bugs.launchpad.net>
>>>> To: tsea...@palladion.com
>>>> References: <20090315074200.12457.19313.malone...@potassium.ubuntu.com>
>>>> Public bug reported:
>>>> The current (2009-03-12) PyPI distribution for Zope2 2.12.0a1 is broken.
>>>> 'easy_install'ing it leads to version conflicts for 'zope.component'
>>>> (3.5.1 versus 3.6.0) in the call of 'mkzopeinstance'.
>>>> ** Affects: zope2
>>>> Importance: Undecided
>>>> Status: New
>>>> The breakage is due to the release of the new zope.prinipalregistry egg.
>>>> We should probably manage a Zope2 indes and tell people to use it when
>>>> running easy_install, because PyPI is not suitable for the task given
>>>> setuptools' "incremental requirements discovery" design.
>>> Easy_installing the a1 sdist should behave like using buildout since
>>> the versions within the sdist are pinned as well. It actually worked
>>> at the time of the a1 release. I don't understand right now why we get
>>> this failure.
>> I don't see any pinning at all here:
> 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.
>> This kind of issue was the source of my contentiont that "released"
>> versions should ship with exact pins of the egg versions (the full
>> transitive closure): it should at least be possible to generate a
>> 'Zope2-exact' distribution which provides a "known good" installation,
>> even it a 'Zope2-upgradable' distribution might be better for some people.
>> The other option, as I said earlier, is to maintain an index for each
>> "release branch" of Zope2, and populate it only with eggs which have
>> been tested not to break the upgrade. We could specify that index in
>> the install docs, and maybe even in the 'setup.cfg' of the package.
> I hope we can discuss and resolve remaining issues during PyCon.
Maybe generating indexes from the varios "known good" metadata we are
already maintaining would be the right path.
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 -