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

"Martin v. Löwis" martin at v.loewis.de
Sat Mar 22 17:06:05 CET 2008

> Huh? How's that? Don't forget that I'm on Windows, and on Windows
> there is no "system tool" - just bdist_wininst, bdist_msi and
> easy_install. The fact that bdist_wininst and bdist_msi link into the
> system UI for listing and uninstallation doesn't make packages using
> them "system packages".

In pje's terminology, they do. He uses "system package" as a shorthand
for "package in a format defined by the system vendor", not as
"package supplied by the system vendor" (IIUC). So .msi files and
self-extracting .exe files are all "system packages", as opposed to
.eggs (which are in a format that wasn't defined by the system vendor).

> The only fly in this ointment is bdist_msi, which uses MSI format,
> which is a lot nearer to a Windows "system packager" than anything
> else. Whether that means bdist_msi can't be changed to work with a
> package index rather than (or as well as, I don't care) add/remove, I
> don't know.

If the package database is merely a directory with additional files
in it, one file per package, then most likely both bdist_wininst
and bdist_msi could support that.

If the file needs to contain file names specific to the target system,
then supporting it in bdist_msi is a bit tricky, as one would have
to generate the file at installation time. That's a "custom action";
I'd probably generate a VB script at packaging time which is then run
at installation time to edit the package database.

> The "one way to do it" uninstaller should be able to uninstall
> everything. If it needs to call the system uninstaller for a specific
> package, there's nothing wrong with doing that. But why tell me to run
> a different command? Just do it for me. I only want one UI, the rest
> is implementation detail.

The uninstallation procedure of the system installer probably has
a separate UI which can't really be suppressed.

For example, uninstallation may be rejected as additional applications
rely on the package, or uninstallation could cause automatic removal
of prerequisite packages that are then no longer used, all requiring
user confirmation.

Also, on some systems, it's difficult to know what specific tool
to run to interact with the system packaging. On some systems,
you have a choice of multiple command-line, text mode, and GUI
tools, some of which may not be installed, or may fail to work
(e.g. when you don't have the windowing system running, and the
tool is a windowed one), or may not be the user's preference.


More information about the Python-Dev mailing list