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

[zooko]

On May 1, 2008, at 2:51 PM, glyph at divmod.com wrote:

> 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.

I use distutils (or setuptools) plus GNU stow to solve the following  
subset of your complaints:

> The #1 reason:
>
>  * distutils does not provide an uninstaller.

...
> * 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

GNU stow + distutils or setuptools solves all of the above for me.   
It does not solve the following:

>  * 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.)

Why indeed?  I personally prefer to distribute my code in the form  
of source .tar.gz's which are to be installed either with  
easy_install or by untarring them and running "setup.py", and I  
prefer to re-use code from other people in that same format.

Regards,

Zooko