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

Alexander Michael lxander.m at gmail.com
Sat Mar 22 14:21:18 CET 2008

On Fri, Mar 21, 2008 at 9:31 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>  The objections to the PEP remain the same as they were then,
>  though: In the requirements, it says "we need", without saying
>  why we need. It then goes on saying "we want" (rephrased)
>  "to duplicate APT and RPM", without saying why we want that,
>  or why that brings us closer to what we need.
>  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. Nevertheless, the many
use cases are related at some level and would benefit from some form
of lowest-common-denominator support in the standard library. As an
example, IF I wanted to use a library to support multi-version
packages or one to ensure I had all the dependencies, I would need to
know what versions of things were currently installed. I can't create
a library to provided these functionalities and use it downstream of
the package creator without some form of standardization to report
package versions. (Or at least without running into the assimilation
problem that setuptools has).

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.


More information about the Python-Dev mailing list