Re: Status report on python2 transition
On Thu, 12 Jul 2001, Carel Fellinger wrote:
> On Thu, Jul 12, 2001 at 09:03:07AM +0200, Jérôme Marant wrote:
> > Bruce Sass <bsass@freenet.edmonton.ab.ca> writes:
> >
> > > Surely adopting a convention of...
> > >
> > > #!/usr/bin/env python[major.minor]
> > >
> ...
> > I object to this. It make scripts not portable to other systems as
> > it currently does with current python 2.0 scripts in Debian.
>
> True as this might be, the above scema still doesn't address all needs.
> The simple case were your script only runs with e.g. 2.1, is covered,
> but what happens when a newer Python is released? Is your script then
> still running with 2.1? Or do we need to update all scripts in order
> for them to use newer Pyton releases?
Right, it is not ideal, but it is portable.
> The following scema will address such matters:
>
> #!/usr/bin/env python[[major[.minor][-][major[.minor]]]
...but is not necessarily portable because Python installs executables
under bin/python{,<major>.<minor>}.
I'm a little confused...
A solution to the problem has already been proposed in previous
discussions on this list -- and I though it had already (at least)
started to be implemented...
bms:~# ls -l /usr/bin/python*
-rwxr-xr-x 2 root root 3040 Apr 10 02:09 /usr/bin/python
-rwxr-xr-x 2 root root 3040 Apr 10 02:09 /usr/bin/python1.5
-rwxr-xr-x 1 root root 3080 Jun 23 15:52 /usr/bin/python2
lrwxrwxrwx 1 root root 7 Jun 24 18:34 /usr/bin/python2.0 -> python2
...'cause I've never seen a 3k python executable. So, using an
explicit "python-wrapper" in the #! line is a step backwards to me.
Unless Python grows the smarts to figure out on its own that there is
more than one version of itself available, and which version should be
used (not as straightforward as just looking at the code)... the only
reasonable solution is to replace bin/python with something that has
those smarts, the next best is to be explicit about which Python the
program is targeted for.
<...>
> The above seems complicated, but versioning a language is complicated.
> But take heart, Python manages to be fairly downwards compatible, so
> the upper bound might not be needed that often, though it is there
> for power users trying out stuff tied into specific releases.
Yes.
I think it is perfectly reasonable for Debian to insist that a
specific version of Python be installed, and that any Python programs
distributed by Debian must work with a certain version of Python or
better. You can then use an unversioned python executable and not
worry about breakage when the specific minimum version of Python
required by Debian gets bumped up, because Python is backwards
compatible. The people who are gonna run into trouble then are those
that try to point bin/python at python<major>.<minor>, where major +
minor is less than the minimum version Debian expects.
If Python breaks backwards compatibility... well, you probably have
some editing work to do (as will every other Python developer who
wants old code to run without problems) no matter how the
infrastructure has been set up (either rewriting the code to not use
the obsolete paradigm, or simply specifying a version of python it
will work with).
- Bruce
Reply to: