[sugar] Python: distutils, setuptools, packages, etc
Wed Sep 27 19:48:01 EDT 2006
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.
> 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
> - 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
More information about the Sugar-devel