[Distutils] How we can get rid of eggs for 2.6 and beyond

[Tres Seaver]

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

Martin v. Löwis wrote:

>> Oh, and application installation is (should be) completely different.
>> On Windows, applications should probably be bundled with their own
>> Python interpreter, a la py2exe. On Unix/Linux, I don't know what the
>> standard is, so I'd have to defer to others.
> 
> This I disagree with. I think it's an overall bad thing to have all
> kinds of applications ship their own copy of Python; see also Aza
> Raskin's PyCon keynote.
> 
> On Linux, python typically comes with the system pre-installed;
> it is not even an option not to have it, except for minimalist
> installations. So if you write python scripts, you typically
> expect that #!/usr/bin/env python works; you might put python2.5
> there if you don't trust that system one is "good enough".
> 
> For installing the application, you typically want the choice
> betaween a "system installation" (in /usr/bin, or perhaps
> /usr/local/bin), and a "user installation". As distutils supports
> both cases, it works fairly well for applications as well.

Sharing the system python is hugely problematic on a unix box which
actually *uses* python for its own tools:  the application is not "safe"
from additions / updates / removeals of the packages in
/usr/lib/python2.x/site-packages done to support those system tools.
The problem gets worse as multiple non-system applications install files
there:  e.g., the 'twisted' package on Debian boxes depends on an
ancient version of 'zope.interface', which can't be used with any
currently supported version of Zope.

virtualenv makes using the system python on such systems somewhat more
tolerable, because each virtualenv can be isolated from the
site-packages of the "host" environment (and therefore from the other
applications).  You still have to live with the choices the system
packagers make (UCS4, for instance), but the pain is at least tolerable.

For a long-running Python application (as opposed to desktop tools or
scripts), installing a custom Python is the "safest" choice:  it
insulates the application not only from unexpected system-driven
site-packages changes, but also allows greater control over other Python
configuration choices (the UCS2 / UCS4 knob, etc.).



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

iD8DBQFH6Cqi+gerLs4ltQ4RAlqZAKCxr2lraLSycVsksYAevtf+urALOgCeLzs9
fE2g7IAb+22B+UbSUFPqj4w=
=re0h
-----END PGP SIGNATURE-----