[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 12:33:49 CET 2008


> Ok, well, I have a rationale for it: make it possible to get rid of eggs 
> as a mechanism for supporting easy_install.  Many people (yourself 
> included) have criticized eggs as an installation mechanism, and this is 
> an alternative that gets rid of .egg files and directories in that case, 
> and most of the need for .pth file usage as well.

How so? I cannot see the need for .egg files or .pth files in the
first place. If they exist so that you can import stuff: just install
to site-packages, and be done.

> The data isn't for them to use to meet their use cases, it's for them to 
> *provide* so that Python tools don't stomp on, uninstall, or otherwise 
> interfere with files installed by the system.  In other words, for 
> system packagers, it's a communication from the system to Python, rather 
> than the other way around.  Even though the distutils will build the 
> file in the bdist, the system packaging tools would be free to generate 
> their own file listing and signatures and such.

Ok, that's a reasonable requirement. It will be difficult to implement,
though, as it will require Linux distributors (in particular) to include
the database snippets in their packages.

Essentially, one would have to contribute patches to all the 
distributions (we care about, at least), and then nag the respective
maintainers to include these patches.

> I probably should have brought this up, in fact, I think I mentioned it 
> in a previous thread, but I would like to see PEP 262 add a way to say 
> "this is a system-installed package, *don't touch*".  The idea again is 
> not to do the job of the native packaging system, but rather to ensure 
> that Python-specific tools (e.g. easy_install and friends) do not 
> interfere or conflict with it.

Something like a read-only flag?

For those without the read-only flag, the specification should
explicitly say what manipulation is allowed.

Regards,
Martin


More information about the Python-Dev mailing list