Re: Status report on python2 transition
On Jul 12, Bruce Sass wrote:
> On 12 Jul 2001, Jérôme Marant wrote:
> > Bruce Sass <bsass@freenet.edmonton.ab.ca> writes:
> >
> > > Surely adopting a convention of...
> > >
> > > #!/usr/bin/env python[major.minor]
> > >
> > > ...is preferable.
> > >
> > > It does the same thing without additional runtime overhead and
> > > without creating a class of Debian-specific Python programs.
> >
> > I object to this. It make scripts not portable to other systems as
> > it currently does with current python 2.0 scripts in Debian.
> > We shall end up with this trick as soon as possible.
>
> How not portable?
>
> Any build of Python I have done installs both:
>
> bin/python<major>.<minor>
> and
> bin/python
>
> as hardlinks...
>
> ...calling "python-wrapper" to execute the program is definately not
> portable to other systems.
True... but it would only be done by Python scripts in Debian packages
that depend on external modules.
The problem with a hardcoded version in the #! path is that it locks
the script into running with that version. Let me give you a "for
instance":
- I create a package that uses and depends on python-newt.
Python-newt is only supplied for Python 1.5 at the moment, so I
hardcode a call to /usr/bin/python1.5
- python-newt's maintainer releases a new python-newt that works with
python 2.1, and drops python 1.5 support.
- I install the new python-newt (and probably a lot of the python-2.1-*)
- My package is now broken and I have to reupload it, even though all
I need to change is the #!.
With python-wrapper:
- python-newt's maintainer does the right black magic with the
python-wrapper business.
- I create a package that uses and depends on python-newt.
I call /usr/bin/python-wrapper.
- python-newt's maintainer releases a new python-newt that works with
python 2.1, and drops python 1.5 support.
- I install the new python-newt (and probably a lot of the python-2.1-*)
- My package still works fine, since python-wrapper knows that this
version of python-newt needs python 2.1 to run.
Now, two questions arise from all this:
- Are we willing to have One and Only One Python in each stable
release? If so, screw this python-wrapper business. It really
doesn't solve any problems with locally-installed Pythons, except by
making sure Debian packaged python programs don't use local pythons.
But we will need to figure out some way to cleanly deal with not
having python 1.5 in woody (a long Conflicts line looks likely).
- If we aren't willing to do this, then we either live with a lot of
messy dependencies that have to be updated every time a new x.y python
comes out, or go with something like python-wrapper that leaves
dealing with new Pythons mostly painless.
The only other solution is to call "python-wrapper" /usr/bin/python,
and make it fallback to calling a Python interpreter (defined by
alternatives or whatever) if no suitable wrapper is found. That is
completely portable, except in the case where /usr/bin/python is
expected to be an ELF binary (does freeze need this?), but it adds
overhead to every invocation.
I have nothing invested one way or the other, mind you.
Chris
--
Chris Lawrence <cnlawren@olemiss.edu> - http://www.lordsutch.com/chris/
Instructor and Doctoral Student, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5949
Reply to: