[Zope-dev] [Fwd: [Bug 343079] [NEW] Broken distribution (2009-03-15)]

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 <dieter at handshake.de>
>>>> Reply-To: Bug 343079 <343079 at bugs.launchpad.net>
>>>> To: tseaver at palladion.com
>>>> References: <20090315074200.12457.19313.malonedeb at 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:
> 
>>  http://svn.zope.org/Zope/tags/2.12.0a1/setup.py?rev=97288&view=auto
> 
> 
> 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.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at 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

iD8DBQFJvnyA+gerLs4ltQ4RAiZ2AKCZ8KW2700uFQMQgX/UWggBfXo4pQCglqMV
O2wVPbaBQzLjFLj/RW7AsuY=
=4Lix
-----END PGP SIGNATURE-----