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

[Alexander Michael]

On Tue, Mar 25, 2008 at 1:45 PM, Luis Bruno <me at lbruno.org> wrote:
> Phillip J. Eby escreveu:
> > Of course, one possible solution is for both A and B to depend on a
>  > "virtual package" that contains C, such that both A and B can install
>  > it if it's not there, and list it in their dependencies.
>  No need. Is this is what you want?
>  http://www.debian.org/doc/debian-policy/ap-pkg-diversions.html
>
>  I've not-so-recently advocated actually building .debs/.rpm/.whatever
>  instead of reinventing wheels in .eggs. Maybe that would be an
>  worthwhile discussion.

I included this as an alternative in my stab at a rationale and
lead-in to a proposal. You can see Floris Bruynooghe's response
earlier in the thread, but basically it is an even harder problem to
create packages for every major platform automatically than it is to
create a simple database of installed packages that plays well with
every major package manager. How did you advocate solving this
problem? I agree that if every python package provided a
MSI/DEB/RPM/MPKG/etc., then there wouldn't be a need to install python
packages without a system-level installer. It just doesn't seem
practical to achieve that, so there remains, at the very least, the
need to provide a programmatic means to determine what versions of
what things are currently installed in your python environment. Well,
when I say "at the very least" I'm assuming that one can accept that a
non-negligible portion of the python community would like to maintain
and use a tool to help automate the task of adding or removing python
packages not available as system packages.

That said, my motivation for including at least briefly a list of
alternatives was to encourage others to flesh them out a bit more (or
porpose new ones) as maybe one of them really is a better! I
personally like the switchable sub-environment idea even though it
only side steps the issues instead of solving them.