Hi,
I am wondering what defines the "default python", is it the one any
Python using Debian-native package must depend on, the one used by
python-support[1], the one all python dependent packages are urged to
work with, one meeting some other criteria, an arbitrary choice?
As I try to catch up with Debian's Python I've noticed a tendency to
view the infrastructure for multiple Python's as a Debian-packaged
Python stuff only kinda thing. e.g.:
line 40 in update-python-modules (from python-support 0.2.2):
"""
py_installed = [ ... os.path.exists('/usr/bin/python'+ver) ]
"""[2]
or Matthias Klose in
http://lists.debian.org/debian-python/2006/01/msg00028.html
"""
- Many developers like to have all (well, maybe the recent ones)
python versions available to be able to test their application with
more than one python version. That's ok, but maybe doesn't directly
belong in a Debian release.
"""
Is it unreasonable to want to install a module package which should work
with any Python and have *.pyc's automatically compiled for an
interpreter which lives in /usr/local/bin, or install a local
interpreter and have Debian attempt to compile all the installed
modules for it, have a local module compiled for packaged interpreters?
Maybe all my questions will be answered when I go through January's
archive, and I don't mean to open up any wounds, but I can't help
finishing Matthias's quote...
"""
Design the packaging in such a way that
it can be used the minimal set of python versions in a Debian and
release and be used to automatically rebuild packages for more python
versions would be a compromise. Now that binary NMU's are a reality,
uploads adding or dropping a python version could be done this way as
well.
"""
...and of course commenting. I have this picture in my head of a
Debian-Python infrastructure that has no pythonX.Y-module packages
because everything is automatically compiled for all available
interpreters. The "default python" would just happen to be the one
python-minimal is a subset of (which may well be an arbitrary choice)
and if an admin wants to use an alternate (maybe even local) Python as
the default they should be able to do so simply by providing the
equivalent of python-minimal for the new default interpreter
(necessarily tweaking any infrastructure code using non-portable
python, which would be a good thing).
My motivation for thinking along these lines is the realization that
large chunks of the current Python Policy could be removed if 2.5 was
implemented in such a way as to make pythonX.Y-anything unnecessary.
- Bruce
[1] At first glance... I don't like having the package providing
Debian-Python infrastructure actually depending on Python (can't help
thinking about potential bootstrap problems, -support getting held up
because the default python fails to build on some arch, etc.) My
concern seems to boil down to having what should be a simple, scripted,
list management and processing task depend on a complex high-level
language. Consequently my first instinct is do redo python-support in
sh or bash.
[2] I would handle the detection of avaiable interpreters (language
issues aside) along the lines of...
interp_dirs='/bin /usr/bin /usr/local/bin'
interp_list=$HOME/found-python-interpreters
test -f $interp_list || touch $interp_list
mv $interp_list ${interp_list}-old
for d in $interp_dirs
do
ls ${d}/python[0-9][.][0-9] 2>/dev/null >> $interp_list
done
...key points being: (i.e., coding issues aside :-) I would look
in /usr/local, and not care what versions of Python Debian knows about.
Why should that, much less which versions are "old" (referring to lines
38 and 39 of update-python-modules), matter to a script whose job is to
manage byte-compilation for Pythons?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
