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... it has too many implications that could break the
> packaging.
Fix the packaging. <shrug> Is there more to it than simply being explicit
(depend on pythonX.Y and use /usr/bin/pythonX.Y) and managing alternatives?
Hmmm, that would effectively create two "default" Python's: Debian's, the
one a user gets because 98% of the modules and apps depend on it; the other
would be defined by /usr/bin/python -> ??? and would only affect local
code and plain "$ python" calls.
> > 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
thanks, I still have a lot of catching up to do
> > [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... :-)
Unless the held up python-support is providing infrastructure used locally,
for interpreters Debian knows nothing about... ;-)
- Bruce
Reply to: