multiple pythons and the default
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]
Re: Thoughts on apps supporting multiple versions of python
On Mon, May 01, 2006 at 08:57:17PM +0200, Marc Dequènes wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > >> Any summaries, partial specs, top level descriptions, particularly good > >> explanations of the stumbling blocks, etc., available for reading? > > https://wiki.ubuntu.com/PythonRoadmap > Is this Ubuntu roadmap of any concern for Debian ? Is doko not able to > make proposal and discuss it with the Debian Python Maintainers ? Seems > another evidence a team work with this guy is impossible. > > http://wiki.debian.org/IRC/debian-tech/Logs/20051120-python-policy > As i see, you've got many questions for which many people on this list > surely know the unswer for years. Why then do you discuss the policy > with people not involved in the Python packaging ? is that to be > discussed in an office far from reality ? Wow, what a constructive response. You've surely been on this list for years and must know all the changes that need to be made to Debian's python policy. Why didn't you reply to Bruce's original question with your own superior write-up of this policy? Seems evidence that teamwork with you is impossible. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: multiple pythons and the default
On Sat, 06 May 2006, Bruce Sass wrote: > I am wondering what defines the "default python", is it the one any /usr/bin/python provided by the "python" package. Right now it's 2.3.5. Supporting other versions apart from this one is only a convenience issue for our users. Right now we have many python2.4-* because python 2.4 really is what people uses to develop new stuff. If we managed to move to python 2.4 sooner, we probably wouldn't have so many python2.X-* packages. > 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. > """ I would love to have a single python version in Debian, just like we managed it with Perl. > 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? This is a possible improvement for python-support, I don't see a major problem with it. > ...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. This is a nice goal yes. But as doko noticed it, it's difficult to achieve for binary modules. > 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). I don't think that the admin should be allowed to change the default python version... it has too many implications that could break the packaging. > 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. Please review doko's python-central package which is a start in that direction. But until this infrastructure is ready, we need to move to python 2.4 by default... we still have the time to fix the packaging for python 2.5 after that. http://wiki.debian.org/DebianPythonTODO > [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 Wrong problem IMO. python-support is a simple python script which should work with any python version. And if python doesn't build on a given arch, what's the point of having python-support work? If python doesn't work, there's no need for python modules... :-) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiple pythons and the default
Le samedi 06 mai 2006 à 04:29 -0600, Bruce Sass a écrit : > 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? I think this is unreasonable, yes. While we can maintain a list of python versions packaged for Debian and ensure they are all working correctly with e.g. python-support, trying to detect other versions and to compile modules for them would be too much error-prone. I have too much background of incomprehensible bugs that turned out to be caused by a user installing broken stuff in /usr/local. > ...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). This is what python-support tries to achieve. However this is only possible for modules written in python. Modules written in C need to be built for every python version they support. > 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. The python policy surely needs work. I wish I had more time to work on it, and still hope to bring up a new draft soon, but everyone is free to work on it as well. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: multiple pythons and the default
On Sat May 6 2006 05:11, Raphael Hertzog wrote: > On Sat, 06 May 2006, Bruce Sass wrote: > > I am wondering what defines the "default python", is it the one any > > /usr/bin/python provided by the "python" package. Right now it's 2.3.5. So it is arbitrary, as in there is no technical reason which makes 2.3.5 most suitable. Therefore it should be possible to choose any Python as the default so long as the dependencies of any package depending on the official default Python can be satisfied, and any problem encountered in doing so would be problems with the implementation of a "default". > Supporting other versions apart from this one is only a convenience issue > for our users. Right now we have many python2.4-* because python 2.4 > really is what people uses to develop new stuff. > > If we managed to move to python 2.4 sooner, we probably wouldn't have so > many python2.X-* packages. I think this is a mistake, on two counts. Debian's support for multiple interpreters should be more than a convenient apt-get install some other Python interpreter, it should be the infrastructure necessary to manage multiple Pythons. Consider that if the system is designed so that an admin can easily change the default Python, then Debian can also. If a package depends on Python-2.4 then it should actually depend on python2.4 and not some other package which just happens to pull in the necessary interpreter... it seems to me this is pretty much the same situation which lead to the discussion that generated the first Python Policy. Back then (3-4 yrs ago?) the problems seemed to be caused by trying to rotate different versions of Python through the same package name --- the convenience of a "default Python" (as in "apt-get install python" does something useful) is for the users, not package maintainers who should be explicit about what their package needs. > > 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. > > """ > > I would love to have a single python version in Debian, just like we > managed it with Perl. Hmmm, doesn't Python dev progress faster than Perl and need a broader base of installed versions to support all the apps and modules, pretty much necessitating more comprehensive support for Python-s than for Perl-s? I'm all for Debian shipping one Python if it can handle all the packaged modules and apps, and for shipping the least number of interpreters even if that means dumping packages; best case for me would be having a bunch of largely unused infrastructure for supporting multiple Pythons. > > 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? > > This is a possible improvement for python-support, I don't see a major > problem with it. > > > ...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. > > This is a nice goal yes. But as doko noticed it, it's difficult to achieve > for binary modules. Ya, small things could be provided in one package if the number of interpreters was whittled down to two, trivially for all things if down to one. I asked Python's BDFL early on in the 2.x series what was up with all the major changes, the replies where essentially that 2.x is for language changes and the 3.x series will be more stable in that respect. If that is still "the plan" then it may be feasible even with binary modules at some time, 'til then we probably need pythonX.Y-module packages. I'm working under the assumptions that 3.x will be more stable, Debian has an excellent opportunity (now, while the environment exists) to work out the details of managing multiple versions and transitions, and that codifying it will actually ease the work load of maintainers and improve the quality of Debian's Python. > > 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). > > I don't think that the admin should be allowed to change the default > python version...
