[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