[Python-Dev] PEP 376

[Paul Moore]

2009/6/30 Tarek Ziadé <ziade.tarek at gmail.com>:
> On Tue, Jun 30, 2009 at 8:37 PM, Paul Moore<p.f.moore at gmail.com> wrote:
>> - The terminology and focus feels setuptools-inspired (my apologies if
>> that's not the case). Expect pushback from setuptools haters...
>
> setuptools implemented *needed* features, like a way for developers to browse
> installed packages.

No problem with any of that. Please understand that on the whole, I'm
in favour of the setuptools features. (While I dislike intensely some
of the setuptools "ecosystem", such as easy_install. In fact, one of
my goals in wanting this PEP accepted is to ensure that I can get the
"good bits" of setuptools, without having to buy into the
easy_install, dependency management, automated download infrastructure
that currently goes with it).

> We said during the summit at Pycon that we wanted this feature in
> Distutils, (Guido said so)

"We" in this context denotes the people at the summit. Please remember
that people who weren't there still have an opinion - and it may well
differ. I'm not saying that it *does* differ, just that the view of
the summit should not be viewed as conclusive (unless the way Python
is developed is very different from how I understand it).

> So I worked in PEP 376 to introduce them.

And as with any PEP, that's a difficult and thankless task (I got a
taste myself with PEP 302, and that was far easier), so just for the
record, you have my thanks for doing this.

> Now if the fact that we want to introduce the good ideas of setuptools
> into distutils,
> (problems Phillip resolved) will make people push it back *even* they
> are good idead, needed features,
>  is something we need to fight against.

But there *are* issues with setuptools. Some users have mentioned them
on a number of occasions. I've raised a few myself. By all means
introduce the good ideas into the core - but make sure people agree
that the ideas *are* good.

And remember - all I said was that people may react against the
setuptools-style terminology. Not that they dislike the *idea*, just
that they might dislike the way it's presented. After all, one common
complaint with setuptools (and one that I agree with) is that its
documentation is obscure to the point of being hostile.

>> - It's quite dense for the casual reader not familiar with the
>> terminology. I've never managed to read the whole thing through,
>> personally.
>
> I'll try to add a definitions section,

Thank you. I'll try to make the time to go through the PEP and comment
more fully.

>> [1] I'd actually like it if the PEP defined an uninstall command -
>> something like "python -m distutils.uninstall packagename". It can be
>> as minimalist as you like, but I'd like to see it present.
>
> it's already there:
>
> http://www.python.org/dev/peps/pep-0376/#adding-an-uninstall-function

No, that defines an API, which as stated in the PEP, "allows a
third-party application to use the uninstall function and make sure
it's the only program that can remove a distribution it has previously
installed". It does NOT define a standard uninstall command, to
complement the standard install command.

Paul.