-----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@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-----