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

Floris Bruynooghe floris.bruynooghe at gmail.com
Sat Mar 22 15:31:16 CET 2008


On Sat, Mar 22, 2008 at 01:46:42PM +0000, Paul Moore wrote:
> All this talk of "playing nicely with the system packager" seems to
> imply that people are designing a second solution, and trying to
> manage the interaction, rather than deciding on *one* solution (which
> by definition has no interaction to worry about).
> 
> It's reasonable to have multiple solutions for multiple Python
> installations (system packager for the system python, python packager
> for a local install, for example) but that's a different matter.

My server runs stable version of Debian, etch currently.  It has
python installed and most of the modules I need.  However not all
possible python modules are packaged but I as the local admin might
decide a certain module -say pyprocessing- is really required for us
and stable enough to use.  I now need to install this locally.  What I
don't want in install an entire new python and hunt *all* modules and
then make sure that the correct applications on my server use the
correct python.

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

An application packaged by the system (Debian in my case) will need to
use the system modules.  For the same reason we invented shared
libraries instead of static libraries.  When I have to install an
application as local admin then I try to run it with the system
python, using as many system modules as possible.  If that's not
possible (e.g. I need a sandbox) I'll often seriously reconsider
installing that application.

As a user I have no problems with trying out an app in virualenv or
something like it.

Regards
Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org


More information about the Distutils-SIG mailing list