Last night I had an idea for organizing multiple python versions in
Debian.
o all core (the interpreter) python packages will be versioned
ex
python-1.5.2
python-2.0
python-2.1.1
Each of these will contain /usr/bin/pythonX.Y.Z and "provide"
'python'.
/usr/bin/python will refer to the newest version, or could use
the alternatives technique to let the admin select a default
version. This is for non-Debian specific scripts that use the
traditional #!/usr/bin/env python, or for quick (non-Debian
specific) scripts that don't care what version they run on. It is
also useful to simply run "python" to get an interactive prompt.
o all other packages will have a versioned depends on the lowest
version it runs with, also a max version if it exists
o The #! line should look something like
#!/usr/bin/deb_py_ver 1.5.2 -
for a program that works with python 1.5.2 and up.
If a program works with only 1.5.2 and 2.0 it would look like
#!/usr/bin/deb_py_ver 1.5.2 2.0
o /usr/bin/deb_py_ver will be a script/program that takes 2
arguments, a min version and a max version of python that can be
used to run this script. It will have a database of the installed
python versions and it will find the newest version that fits
within the requested range to run the script with. A '-' can be
substituted for a version to denote "any" or "no limit" in that
direction (either min or max).
Rationale :
Python is smart -- it knows where to find itself (ie libpython)
and the standard library. Unlike java it doesn't need to be told.
This keeps scripts simple and allows them to work with multiple
versions of python. The #! line is Debian-specific, but it is
simple for a maintainer to have a patch for that one line.
Disk space is cheap nowadays (I saw a disk in an add that was
$3/GB). Having a duplicate of .py/.pyc files isn't a major issue.
Most people will only have 1 version anyways and don't need the
extra complexity trying to minimize the disk usage with multiple
versions.
Python developers are not "most users". They will, almost
certainly, have multiple versions that they will want to manage
themselves for testing purposes (such as new development on the
interpreter). These will be in their home directory or /usr/local
and not affect the rest of the package system.
Python app developers can have mulitple pythons installed and use
a "wrapper" script to get a particular version. For example
main.py
main-1.5.2.py
main-2.0.py
main.py will have the "real" 'main'. main-1.5.2.py will have
#!/usr/bin/deb_py_ver 1.5.2 1.5.2
execfile main.py
thus is ensures that it will be run by 1.5.2 and has no
duplication of code. It could just as easily have
#!/usr/bin/python1.5.2 as the first line. main-2.0.py follows the
same pattern.
This is just an idea I had, and I am almost certain that I am
overlooking some issue. Consider this, and (maybe) use it in building
an optimum solution :-).
-D
PS. Thanks Gregor and all for your effort in providing the python
packages.
