[Python-Dev] bdist_* to stdlib? (original) (raw)

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:

bdistdeb, bdistmsi, and friends He explained them as follows: """ bdistdeb makes .deb files (packages for Debian-based Linux distros, like Ubuntu). bdistmsi 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 bdistegg) be included in the next Python release, and there was no opposition there that I recall. """ I don't like the idea of bdistdeb 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