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

[Marco Pesenti Gritti]

Ian Bicking wrote:
> 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.
>

I was actually referring to the build system of the single packages 
here. If you want to hack on sugar you will likely have to hack (or at 
least understand) some of the dependencies. I'm actually thinking to 
sugar as gtk + dbus + matchbox + .... + our python bits, not as the 
python code only. In this context using the same build system have some 
value.

If you want to write a sugar activity then this probably doesn't matter.

Btw it turns out jhbuild already supports distutils.

>> - 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.
>

There will be activities wrote in C, or activities based on application 
already using auto*. Getting these to use distutils would not be 
productive (if possible at all).

But we are going to have documentation on how to write activities and 
bless a build system for activities that are written from scratch in 
python (which should be the most common case). setuptools might be a 
good candidate for this. It would be positive to think and experiment in 
this direction. We want to be really easy to write activities. And I 
would never put auto* and really easy in the same phrase :)

Marco