Re: Status report on python2 transition
On Thu, 12 Jul 2001, Chris Lawrence wrote:
> On Jul 12, Bruce Sass wrote:
> > 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.
Ok
> 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":
<...>
> - My package is now broken and I have to reupload it, even though all
> I need to change is the #!.
ya, bummer.
> With python-wrapper:
>
> - python-newt's maintainer does the right black magic with the
> python-wrapper business.
<...>
> - My package still works fine, since python-wrapper knows that this
> version of python-newt needs python 2.1 to run.
ya, nice. Of course, it is up to you with @debian.org addresses to
ultimately decide if the "black magic" route is best.
> Now, two questions arise from all this:
>
> - Are we willing to have One and Only One Python in each stable
> release?
How about, "bin/python" must meet certain minimum requirements.
Is there any difference between having only one Python installed,
and only using one of the Pythons that are installed?
...and is it OK if that effect is achieved by convention, as opposed
to explicit dependencies?
I must admit, I am thinking of "stable"... is it likely that the (for
instance) version of python-newt is gonna change on you after a
release... or is the example confined to "unstable"?
> 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).
Hmmm, have 1.5.2, 2.0.1, and 2.1.1 in Woody, adopt the convention
bin/python be at least equivalent to python2.0, have any packages
still depending on 1.5.2 explicitly state so and use python1.5 in
their executables (everyone else can assume "#!/usr/bin/env python"
gets you 2.0 or better.
> - 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.
I'm not really sure how messy the dependencies would get (I tend to
only pay attention when something is messed up and I need to edit
.../dpkg/status as a work around), but I would only expect it to be so
(maybe) for those depending on an old version of Python... good
incentive to get it working with a more current Python. ;)
> 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.
The python replacement (a.k.a "python-wrapper") could be an ELF
executable, it may still require a Debianized freeze module, but the
overhead would be less.
- Bruce
Reply to: