[Zope-dev] Don't have "Zope 2" hard-specify its versions!

[Andreas Jung]

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

On 11.04.2009 19:32 Uhr, Tres Seaver wrote:
> Hanno Schlichting wrote:
>> Chris Withers wrote:
>>> Dieter Maurer wrote:
>>>> Tres has earlier proposed a meta egg to represent "versions.cfg" in
>>>> a setuptools only (non buildout) environment.
>>>>
>>>> A meta egg is an egg that only list dependencies and does not contain
>>>> code of its own.
>>> Indeed, so we'd need 2 eggs for Zope 2 :-(
>>>
>>> Something I bumped into recently:
>>>
>>> If the Zope 2 egg actually hard-specifies its dependencies, how do I 
>>> upgrade any of those dependencies to newer versions that fix bugs i may 
>>> have encountered/fixed?
>> You roll your own meta egg. You cannot override hard version
>> specifications inside a setup.py.
> 
>> In all other debates we seemed to agree on not over specifying
>> requirements in setup.py files, I wonder why anybody still tries to
>> follow this route.
> 
> Maybe because it makes for a predictable / reproducible installation?
> After all, the 2.12a1 egg already released is now broken under
> easy_isntall becasse it *doesn't* nail down its dependencies.
> 
> Predicatbility requires one of the following:
> 
> - Run an index, and make people install from there rather than PyPI;
>   at that point, you are a "distribution" maintainer, and can ensure
>   consistency.  Users who trust you can "safely" upgrade at will,
>   because you are responsible for ensuring that the eggs in the index
>   work together.
> 
> - Release a nailed-down egg (or the equivalent buildout.cfg /
>   versions.cfg, and let people install from PyPI.  Upgrades are not
>   really safe: you won't get borked by newly released eggs, but
>   removed / re-uploaded eggs can still hose you.
> 
> - Release some kind of monolith, generated from the same metadata
>   as above.  Upgrades aren't really possible here:  you have to release
>   a new version of the monolith.
> 
> 
> 
>> Let's see what other people who want to support easy_install do: They
>> require you to use virtualenv and create a links page, which has all the
>> dependencies in all the required versions on it:
> 
>> http://pylonshq.com/download/0.9.7/
>> http://www.turbogears.org/2.0/downloads/2.0final/
>> http://dist.repoze.org/zope2/dev/
>> http://dist.plone.org/release/3.3rc2/
> 
>> In order to install from on of these you do for example:
> 
>> easy_install -f http://pylonshq.com/download/0.9.7 Pylons
> 
> You want '-i' and the index URL, not '-f' and the "directory-containing-
> tarballs" URL.
> 
>> and that's it. Some projects package up the multiple steps (including
>> installing setuptools) into a little helper script.
> 
>> As you might notice all that is required is a known URL and Apache
>> serving a bunch of files directly.
> 
> Without supplying the '-i' ('--index-url') flag, you are still subject
> to the variability of PyPI.

A dedicated index is a clean solution (I have not figure out or
understand how this is accomplished for Zope 3). Another low hanging
fruit is releasing Zope 2 as 2 packages (one with unpinned versions
(for buildout) and one with fully pinned versions). I am trying out this
approach for the next a2 release.

Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkniFb8ACgkQCJIWIbr9KYwKWACdEa+VpOliCYnd8M1BLvVFJyHe
70wAoM8XlOrP7PBY0Bxqpf5Lev4GHVSh
=FBm9
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090412/60093e13/attachment.vcf