[Python-Dev] bdist_* to stdlib?

Bob Ippolito bob at redivi.com
Wed Feb 15 00:14:29 CET 2006


On Feb 14, 2006, at 2:05 PM, Joe Smith wrote:

>
> "Guido van Rossum" <guido at python.org> wrote in message
> news:ca471dc20602131604v12a4d70eq9d41b5ce543f3264 at mail.gmail.com...
>> In private email, Phillip Eby suggested to add these things to the
>> 2.5. standard library:
>>
>> bdist_deb, bdist_msi, and friends
>>
>> He explained them as follows:
>>
>> """
>> bdist_deb makes .deb files (packages for Debian-based Linux  
>> distros, like
>> Ubuntu).  bdist_msi makes .msi installers for Windows (it's by  
>> Martin v.
>> Loewis).  Marc Lemburg proposed on the distutils-sig that these and
>> various
>> other implemented bdist_* formats (other than bdist_egg) be  
>> included in
>> the
>> next Python release, and there was no opposition there that I recall.
>> """
>>
>
> I don't like the idea of bdist_deb very much.
> The idea behind the debian packaging system is that unlike with RPM  
> and
> Windows, package management should be clean.
>
> Windows and RPM are known for major dependency problems, letting  
> packages
> damage each other, having packages that do not uninstall cleanly (i.e.
> packages that leave junk all over the place) and generally messing  
> the sytem
> up quite baddly over time, so that the OS is usually removed and
> re-installed periodically.)

This is one problem that eggs go a LONG way towards solving,  
especially for platforms such as Windows and OS X that do not ship  
with an intelligent package management solution.

The way that eggs are built more or less guarantees that they remain  
consistent, because it temporarily replaces file/open/etc and some  
other functions with sanity checks to make sure that the installation  
layout is self-contained** and thus compatible with eggs.  It's not a  
real chroot, of course, but it's good enough for all practical purposes.

The only things that easy_install overwrites** in the context of eggs  
are other eggs with an identical filename (version, platform, etc.),  
unless explicitly asked to do otherwise (e.g. remove some existing  
older version).  Uninstallation is of course similarly clean, because  
it just nukes one directory or .egg file, and/or an associated .pth  
file.

** The exception is scripts.  Scripts go wherever --install-scripts=  
point to, and AFAIK there is no means to ensure that the scripts from  
one egg do not interfere with the scripts for another egg or anything  
else on the PATH.  I'm also not sure what the uninstallation story  
with scripts is.

-bob



More information about the Python-Dev mailing list