[sugar] Python: distutils, setuptools, packages, etc

[Ian Bicking]

So, the other topic about package layout, is if and how OLPC should use 
distutils and/or setuptools.

Right now, honestly, I don't understand the Sugar build process (not 
jhbuild so much as the sugar package itself).  I assume it makes sense 
to people familiar with auto* and the configure/make/make install 
pattern.  Honestly I'm not one of those people, so maybe the current 
system handles requirements I'm unaware of.

Anyway, the conventional way to distribute and install a package in 
Python is with distutils.  This involves a file setup.py in the root of 
the package, which describes the package and anything in the build 
process (for pure-Python packages it's very short).  It handles 
compiling extensions as well, but without as much flexibility as 
configure, or as efficient as make.  But in practice it seems to be 
enough flexibility, and certainly enough for OLPC.  And you just have a 
setup.py file, without any other build-related files, which I personally 
appreciate.

Then the build process is:

   python setup.py install

This will build anything that needs building, and copy the result into 
site-packages.  (If using virtual-python.py, it will install it in the 
right location; with the current setup you'd have to give it a --prefix 
option.)

Anyway, you guys probably all know this.  Is there a reason Sugar 
doesn't use distutils?  I don't want to rehash old discussions, but I 
don't know what discussions are old yet ;)

Then the second question is about using Setuptools.  Setuptools is a 
distutils extension that's quite popular; it didn't quite make it into 
Python 2.5 as a standard library module, but probably will be in 2.6 and 
is widely used now.

Some of the features of Setuptools aren't necessarily useful to OLPC. 
Some might be quite useful; the egg format that setuptools is a possible 
application distribution mechanism, for instance.  Setuptools also has 
.pth file handling, as I mentioned in a previous email, which would be 
useful for our development.  It also improves the situation for using 
zip files for Python packages, which may be useful.  And a plugin 
system.  And maybe some other things I can't remember.  All of which is 
a fair amount of Python buy-in; not every OLPC application will be a 
Python application, for instance, so the egg format isn't ubiquitous 
(though it has some similarities to Mac bundles, so it certainly brings 
Python apps closer to what OLPC may implement in a more general form).

Zip files, .pth files, eggs, and how sys.path is setup is all another 
important discussion, but somewhat separate.  How exactly sugar is setup 
is also to some degree separate, as it's a core library and how it gets 
on the system is kind of incidental.  But something like the chat 
application should be a model for how other applications are installed 
and distributed, so it should probably be split off entirely, and then 
these questions do apply there.

This email is too long.  Sorry.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org