[Distutils] Why not distutils? (was Re: [Python-Dev] shal we redefine "module" and "package"?)

[glyph at divmod.com]

I'm not on distutils-sig, but this is probably of little interest to 
python-dev.  Please Cc: me if you think my continued input would be 
useful to this discussion.

On 08:25 pm, zooko at zooko.com wrote:
>>almost always in the phrase, "please do not use distutils to do a 
>>system install of Twisted, use the specific package for your 
>>platform".
>
>This is a tangent, but why do you give that advice?  I typically give 
>people the opposite advice on how to install Twisted.

The #1 reason:

  * distutils does not provide an uninstaller.

This means that a user who has installed a Python library - but 
especially a package like Twisted, which uses a shared namespace with 
other libraries that use it, twisted.plugins - can't easily get rid of 
it.  I only ever use 'setup.py' in conjunction with '--prefix'; in my 
opinion, the *default* behavior of distutils should be "--prefix 
~/.local".

Definitely not the only reason, though.  Even if distutils had a great 
uninstaller, I still probably wouldn't recommend it...

  * distutils will interfere with the system package manager, potentially 
breaking it, by writing files to locations reserved for the system 
package manager (/usr, et. al.)
  * distutils won't uninstall a system-installed version of the package 
first, so if you use e.g. --force to overwrite your system files, you 
may end up with leftover system packaged (incompatible, earlier-version) 
plugins or modules which break your distutils install
  * running arbitrary, non-vendor-supported code as root as a matter of 
habit is, in my humble opinion, bad; distutils requires you to run as 
root for the default behavior to work.  the system package manager 
typically requires root permission too, but at least it's the sort of 
thing which has been audited.
  * not only can you not reverse the process, there's no way to *tell* if 
distutils has crapped all over your system installation of a particular 
package
  * setuptools causes seemingly random breakages (in packages which 
support it), and I don't want to deal with bug reports from users 
related to packaging; packagers are capable of dealing with setuptools' 
interactions with the platform and creating a nice, neat bundle that 
works as expected.
  * when you say "distutils", what do you mean?  running 'setup.py' from 
some random revision of trunk?  doing 'sdist' from trunk, then install? 
Using operating-system packages at least suggests that you're using a 
release, or if not an actual release, you've gone through something 
approximating the actual release/build process that we suggest for 
users.
  * if the user is installing for development anyway, and not for 
deployment, then why bother doing any installation step at all?  It's 
probably better to just drop an SVN checkout on PYTHONPATH somewhere.

And, finally...

  * why bother having installers prepared for particular systems, if they 
are not the preferred way of doing things?  If and when distutils is 
ready to be the thing I will suggest to users, I imagine that we'll stop 
having operating system packages.  (Of course, that begs the question 
why distutils would have commands like "bdist_wininst" - it's difficult 
to beat the native packages for convenience.)