-----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 <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: > >> 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 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 iD8DBQFJvnyA+gerLs4ltQ4RAiZ2AKCZ8KW2700uFQMQgX/UWggBfXo4pQCglqMV O2wVPbaBQzLjFLj/RW7AsuY= =4Lix -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )