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

Paul Moore p.f.moore at gmail.com
Sat Mar 22 15:14:01 CET 2008

On 22/03/2008, Alexander Michael <lxander.m at gmail.com> wrote:
>  >  IOW, the PEP is lacking a rationale.
> It seems to me that this discussion is being undermined by not
>  acknowledging the many use cases up front. There is no rationale
>  because there are too many tacit rationales.

Absolutely! It feels like people are trying to design a solution
without having written up the problem spec. Maybe that's because there
are too many problems for a single solution to work in all cases?

>  My personal use case is for multi-version packages. I deploy many
>  small scripts (not applications) that use an evolving set of base
>  libraries. I don't want the older scripts to hold me back from pushing
>  forward with the base libraries, so I peg the scripts to their
>  respective major versions as I release them.

My personal use case is for a Windows system with a number of adhoc
scripts, which may depend on 3rd party libraries, and a number of
"applications" (3rd party or otherwise) written in Python.

I want the applications to use a bundled Python and library, via
py2exe. There should be no dependency on the "system" Python.

Adhoc scripts can depend on libraries installed into the system
Python, but generally there will be a "base" set of libraries that I
will always have installed and which can be assumed to be present
(pywin32, cx_Oracle, py2exe, ...). Scripts can use these without
restriction but should be prepared to work with whatever version is
present. It should (almost) never be a problem to a script if a
library gets upgraded.

Additional libraries may be installed in the system Python, for
one-off jobs, or for testing and development. I will install and
remove these at will, and nothing critical should break ifn I do.

There is generally no other Python present on the system. On my
development machine, I may have alternative versions installed, and I
may have trunk checkouts with a python.exe built, but these will never
be used for anything other than specific development tasks, and are
treated as "throw-away". It's very rare that any 3rd party library
will be installed in these, and special handling when it does happen
is entirely acceptable.

For the system Python, I need:
- a single way to list what's installed (including version)
- a single way to uninstall items as needed
- a way (or more than one) to install 3rd party software *which ties
into the above*

The key maintenance task I do on the system Python is to list
everything installed, uninstall them all, upgrade the system Python,
then reinstall the ones I had installed previously. (Don't bother
telling me there are other ways I could do this - that's not the point
here, this is how I actually work).

The reason setuptools/easy_install breaks this is because it fails the
"single way" test. I have to use bdist_wininst for some packages, so
setuptools *has* to integrate with that. Also, setuptools doesn't have
the list and uninstall features.

So that's my problem/requirements. Anything that solves this gets +1
from me. Anything else gets -1 or at best -0. Anything that adds extra
features while not solving my problem gets a strong -1, as the extra
features will encourage take-up of that solution, exacerbating my
current problem.


More information about the Python-Dev mailing list