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

[Jim Fulton]

On May 1, 2008, at 4: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.
>
> 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.)

These are very good arguments for not using distutils to install  
packages into a system Python.

Well said.

I'll note that I *never* use distutils that way. :)  (I may be in the  
minority though.)

Jim

--
Jim Fulton
Zope Corporation