So, after having some time to absorb the Python-Dev threads about
setuptools, bootstrap, and all the rest, I think I see an opportunity
to let people route around the "damage" of eggs, while still making
it possible for the people who want to use easy_install or to put
dependencies in their setup.py to get what they want, too. (And
without them needing to install eggs, either.) At the same time, we
can address the issues that remain around uninstalling packages,
system vs. user packages, PYTHONPATH and site.py woes, and really
pretty much every other complaint I've heard in the last few days
about setuptools stomping on other people's stuff. (Even Paul's
Windows issues, hopefully.)
Now, you might be asking, "Okay, so why are you telling me about
this? Why not just go fix setuptools?" Well, I *can't*. Not
without some help from Python-Dev and the Distutils-SIG, to create an
updated standard for installed package metadata, by updating PEP 262
("A Database of Installed Python Packages") to include input from the
system packaging folks, support for namespace packages, and support
for setuptools-compatible dependency information.
What's that got to do with anything? Well, without it, setuptools
can't support uninstall or conflict management without using eggs to
compartmentalize the installed files. And because it has to use eggs
to do *that*, it has to munge .pth files and install its own site.py
when installing to PYTHONPATH. All of this ugliness follows directly
from the absence of a PEP 262-style installation database.
Sure, setuptools could create its own version of this, and I almost
did that four years ago. (If you look at the "open issues" part of
PEP 262, you'll see my comments from back then.) I decided not to
for two reasons: first, the distutils didn't support it yet, so it
didn't help for conflict detection and avoidance in the real world at
that point.
Second, there were no uninstall tools for it, so I'd have had to
write one myself. (Zed's "easy_f'ing_uninstall" to the contrary, it
ain't easy, and I have an aversion to deleting stuff on people's
systems without knowing what will break. There's a big difference
between them typing 'rm -rf' themselves, and me doing it.)
However, if tools exist and are distributed for such a "database",
and *everybody* agrees to use it as an officially-blessed standard,
then it should be possible for setuptools to co-exist with that
framework, and we're all happy campers.
In particular, the "installing eggs sucks" camp should be happy,
because it'll be possible for me (or anyone else) to write a version
of easy_install that doesn't install eggs any more, and
setuptools-based packages can go back to having "setup.py install"
install things the old way by default.
So, to accomplish this, we (for some value of "we") need to:
1. Hash out consensus around what changes or enhancements are needed
to PEP 262, to resolve the previously-listed open issues, those that
have come up since (namespace packages, dependency specifications,
canonical name/version forms), and anything else that comes up.
2. Update or replace the implementation as appropriate, and modify
the distutils to support it in Python 2.6 and beyond. And "support
it" means, "ensure that 'install' and *all* bdist commands update the
database". The bdist_rpm, bdist_wininst, and bdist_msi commands,
even bdist_dumb. (This should probably also include the add/remove
programs stuff in the Windows case.)
3. Create a document for system packagers referencing the PEP and
introducing them to what/why/how of the standard, in case they
weren't one of the original participants in creating this.
It will probably take some non-trivial work to do all this for Python
2.6, but it's probably possible, if we start now. I don't think it's
critical to have an uninstall tool distributed with 2.6, as long as
there's a reasonable way to bootstrap its installation later.
Questions, comments... volunteers? :)
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
