At 10:30 AM 4/9/2008 -0700, zooko wrote:
>PEP 262 sounds like a non-starter to me because
>1. It appears to be backwards-incompatible with setuptools/
>easy_install/eggs, thus losing all the recently gained cooperation
>that I mentioned in the previous paragraph, and
No. It provides a forward-compatibility path for the distutils, so
that easy_install doesn't have to install things in .egg format in
the future. There's no compatibility breakage at all.
>2. It defines a new database file,
No, it defines *files*. One file per installed distribution,
containing (among other things) an installation manifest.
>where I would prefer either:
> a. Doing away with database files entirely and relying on the
>filesystem alone to hold that information, or
...which is what PEP 262 *does*.
Unfortunately, PEP 262's title is bad for marketing, as you've
effectively pointed out. It would be better titled something
"package installation manifests" or "package contents files", or
something of that sort.
> b. Continuing to use the current ".pth" database file format,
>possibly improved by having native support for .pth files in the
>Python import machinery.
These mechanisms are orthogonal to this issue.
>3. Because of #2, it triggers programmers to exclaim "They are
>planning to reinvent apt!", thus making it unlikely that the new
>proposal will recapture the cooperation that setuptools has already
Yeah, we need a new name. Everybody is going off of "database of
installed packages" and thinking "apt", because they aren't paying
any closer attention. However, given that we are discussing this on
Python-Dev and distutils-sig, I do think it's reasonable to expect
(if perhaps not reasonable to receive) that people discussing the PEP
have *read* the freaking PEP first, prior to trashing it or offering
And it's not like I'm personally offended or anything -- I didn't
even write the PEP in question. But what's the point of having PEPs
if people read nothing but their titles? We could just delete
everything but PEP 0. :)
>Perhaps PEP 262 and my proposal are not actually alternatives, but
As I've already pointed out, your proposal does not address multiple
installed versions of a package, and I see no sane way to modify it to do so.
>What I want is for the already implemented, tested, and deployed
>code- re-use features of setuptools/easy_install to be more widely
>accepted. This is best and most easily achieved by fixing the two
>most frequent objections to setuptools/easy_install: 1. That you
>can't conveniently install into an arbitrary directory, and 2. that
>it subverts the meaning of your PYTHONPATH.
As I've already stated, the only way for these problems to be fixed
is for easy_install to not install files in .egg form -- which also
solves the general objection to using .eggs in the first place.
And the only way to do that, is to have a way to keep track of what
files are installed. Rather than have easy_install come up with its
own way of doing that, I would prefer to share a standard with the
distutils. Hence, the PEP discussion.
For earlier versions of Python, it will still be possible to install
and uninstall with setuptools using this approach. You just won't be
able to uninstall pure distutils-based packages, unless you installed
them using easy_install.
Meanwhile, it has occurred to me that the easiest way of handling
compatibility is not to require that other packaging tools mark their
files for non-removability, but simply not allow easy_install to
remove or overwrite anything that *isn't* claimed by a manifest. In
that way, easy_install would be immediately usable in the new mode,
without any updates to Python or to system packaging tools.