[Distutils] hooray for distutils/eggs/setuptools/easy_install

zooko zooko at zooko.com
Tue Sep 23 15:41:21 CEST 2008


On Sep 23, 2008, at 5:53 AM, Russel Winder wrote:

> I guess the question in my mind is if the Ruby community have Ruby  
> Gems,
> what is the Python equivalent, and why doesn't it work?

I'm fairly satisfied with distutils/eggs/setuptools/easy_install.  It  
isn't perfect, but it's good enough, and it is improving thanks to  
Philip Eby, Chris Galvan, Philip Jenvey, Tarek Ziadé, and other  
contributors.

Also, even though there is a sizable fraction of Python programmers  
who don't like it, there is no other tool that has anywhere near the  
vast universe of compatible Python code.  Partially because it is  
compatible with distutils and partly because it is widely accepted  
itself.

There are currently 4,800 packages listed on http://pypi.python.org ,  
in addition to which there are an uncounted number of publicly  
available Python packages that are not listed there.  (By the way,  
there are 783 packages in the Debian unstable Python section --  
http://packages.debian.org/unstable/python -- and 712 packages in the  
Ubuntu Hardy Python section -- http://packages.ubuntu.com/hardy/ 
python ).

There are probably at least 4,800 different programmers responsible  
for writing and maintaining the world's publicly re-usable Python  
packages.  Almost all of these thousands and thousands of packages  
are seamlessly re-usable by setuptools, and if you use distutils or  
setuptools to package and distribute your Python code, then your code  
will be re-usable by those folks (whether they use distutils or  
setuptools themselves).

I get great value from being able to re-use almost any other Python  
package in my code without having to ask my users to manually deal  
with more dependencies, and without having to spend time to create  
platform-specific packages, e.g. Debian packages, Windows installers,  
etc.  But note also that setuptools does not *prevent* me from  
creating such packages.  Currently the standard Tahoe install  
instructions are generic and apply to all supported platforms, but  
Tahoe also gets packaged up as .debs and as a Windows app for  
specific customers.  See also the stdeb tool which is a handy way to  
produce .debs automatically from your Python source code and bbfreeze  
which, I am told, is a good way to produce Windows packages:

http://stdeb.python-hosting.com

http://pypi.python.org/pypi/bbfreeze


Also, I really like setuptools plugins as a way to make build tools  
be separately maintained and packaged instead of piling up in your  
setup.py.  Here are the first few packages which use the new  
classifier "Framework :: Setuptools Plugin":

http://pypi.python.org/pypi?:action=browse&c=524

Hopefully in the future more of these packages will get classified as  
being setuptools plugins that are useful for development:

http://pypi.python.org/pypi?% 
3Aaction=search&term=setuptools&submit=search


My major project, Tahoe, has been using setuptools for more than a  
year now.

Here are the installation instructions for Tahoe.  Note that these  
instructions are the same for all supported platforms, which includes  
Windows, Cygwin, Mac, Linux, and Solaris.

http://allmydata.org/source/tahoe/trunk/docs/install.html

Here is the list of Python packages that Tahoe needs (not including  
the packages that *those* packages need, such as pyOpenSSL and pyutil):

http://allmydata.org/trac/tahoe/browser/_auto_deps.py

And here is the list of open tickets about how we would like to  
improve Tahoe packaging:

http://allmydata.org/trac/tahoe/report/10

Regards,

Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month


More information about the Distutils-SIG mailing list