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

["Martin v. Löwis"]

> I'm making the assumption that the author(s) of PEP 262 had good 
> reason for including what they did, rather than assuming that we 
> should start the entire process over from scratch.

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.

>> Anything more complicated should be left to tools which are
>> specifically written to manage complex software setups.
> 
> Tools which will need this data, in order to do their work.  Hence, 
> the reason for standardizing the data, instead of the tool(s).

If there was a chance that the infrastructure being developed
actually helps these tools, *that* would be a reasonable goal,
IMO.

However, I'm extremely skeptical that this can ever succeed
to the degree that whoever provides RPMs, .debs, or MSI
files will actually use such data, as they will find that
the data are incomplete, and they have to redo all of it,
anyway.

> I'm proposing, rather, that we finish the vision of PEP 262, of 
> having a standard specification that *all* tools will abide by -- 
> including rpm, dpkg, and what-have-you.

Do you also envision the objective of PEP 262, then? I.e.
to provide a database of installed packages, in .../install-db?

> And as I said, I'll be happy if all we do is get the distutils to 
> abide by the spec for 2.6, even if it means we don't get an uninstall 
> tool.  That can always be installed later using Guido's bootstrap tool.  :)

I'm even more skeptical here. If the assumption is that the package
database allows for uninstallation, I'm -1. IOW, RPM, deb, MSI
should then *not* write to that package database, as they also write
to a different database, out of the scope of the PEP, and this is
what uninstallation should use.

Regards,
Martin