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

[Ian Bicking]

Marco Pesenti Gritti wrote:
> Ian Bicking wrote:
>> 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.
> 
> Hi,
> 
> I can't comment on the technical merits of distutils since I never used 
> them. Generally everyone hates auto* but as Dan mention it's a very 
> flexible system.
> 
> Anyway the reason we chose automake to start with was:
> 
> - All the sugar dependencies use it. There is some value in a consistent 
> build system for the whole software stack.

I assume at some point distutils installations will be part of the build 
system as well, as it is nearly universal in the Python world, and at 
some point we'll be using external tools or libraries.  I actually wrote 
the email after I wanted to install nose 
(http://nose.python-hosting.com/) into the environment, and had to 
fiddle a little bit to do it.

But, especially with a custom Python build, supporting distutils is not 
particularly hard.  I assume getting jhbuild to run "build/bin/python 
setup.py install" is not hard.  It's just any weird CFLAG stuff that's 
hard, and I'm guessing that packages already using distutils will have 
that worked out in an okay way (knock on wood).  In theory, once this is 
all worked out, configure won't even be necessary -- everything will be 
locked into a known location and for each new project that is 
incorporated maybe we'll need to tweak something here or there but then 
it's set.

> - The whole GNOME tools ecosystem is based on auto*. Just think about 
> jhbuild or pkg-config.
> - Sugar will end up being a mix of C and python code.
> - We are familiar with it.
> 
> Still I think it might bw worth considering distutils as one of the 
> option for external activities. It might just be easier for people that 
> are not familiar with auto*. In general I think the bundles 
> specification should be kept independent from any build system (and I 
> think it is atm)

I feel reasonably confident that distutils -- and actually moreso 
setuptools -- would be the proper basis for making Python-based apps 
into bundles.  Sugar itself isn't an app, though currently it does 
include some apps, so maybe this doesn't apply to Sugar itself.

So yeah, I don't think what Sugar itself uses matters all that much, so 
whatever you're all comfortable with.  There's a few useful features 
using distutils and setuptools, but they aren't anything too magic.

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