I'm thinking that the Sugar jhbuild should probably use
virtual-python.py: http://peak.telecommunity.com/dist/virtual-python.py
Alternately (and particularly if OLPC goes to Python 2.5), Python should
be built as part of the build process. virtual-python basically
symlinks Python so it doesn't pick anything up from the global
installation. It's like building a custom Python, but faster since it
doesn't actually build anything.
Then instead of relying on $PYTHONPATH to control the environment, using
build/bin/python will use the custom environment. (And of course,
having that directory first on $PATH will make "python" work as well.)
Would building 100% of the OLPC software be prohibitive (either to build
the software, or setup the build process)? That would then give us a
completely accurate system and process.
Almost unrelatedly, I think Python 2.5's enhanced generators
(http://www.python.org/dev/peps/pep-0342/) could be syntactically
appealing for doing async DBUS messages. I just mention this as another
point in 2.5's favor, and because it occurred to me just now.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
