Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8957 > unrolled thread

/usr/bin/python2 shebangs

Back to article view | Back to linux.debian.maint.python

Contents

  /usr/bin/python2 shebangs Barry Warsaw <barry@debian.org> - 2016-11-01 15:30 +0100
    Re: /usr/bin/python2 shebangs Scott Kitterman <debian@kitterman.com> - 2016-11-01 16:40 +0100
      Re: /usr/bin/python2 shebangs Barry Warsaw <barry@debian.org> - 2016-11-01 22:20 +0100
        Re: /usr/bin/python2 shebangs Scott Kitterman <debian@kitterman.com> - 2016-11-01 23:10 +0100
          Re: /usr/bin/python2 shebangs Donald Stufft <donald@stufft.io> - 2016-11-02 01:50 +0100
            Re: /usr/bin/python2 shebangs Scott Kitterman <debian@kitterman.com> - 2016-11-02 02:10 +0100
            Python 4 and ‘python3’ (was:  /usr/bin/python2 shebangs) Ben Finney <bignose@debian.org> - 2016-11-02 04:00 +0100
              Re: Python 4 and ‘python3’ (was:  /usr/bin/python2 shebangs) Barry Warsaw <barry@debian.org> - 2016-11-02 15:10 +0100
                Re: Python 4 and ‘python3’ Ben Finney <bignose@debian.org> - 2016-11-02 23:30 +0100
                  Re: Python 4 and ‘python3’ Barry Warsaw <barry@debian.org> - 2016-11-02 23:50 +0100
                    Re: Python 4 and ‘python3’ Ben Finney <bignose@debian.org> - 2016-11-03 00:50 +0100
          Re: /usr/bin/python2 shebangs Thomas Goirand <zigo@debian.org> - 2016-11-07 11:50 +0100
            Re: /usr/bin/python2 shebangs Barry Warsaw <barry@debian.org> - 2016-11-07 16:10 +0100
              Re: /usr/bin/python2 shebangs Scott Kitterman <debian@kitterman.com> - 2016-11-07 16:30 +0100
                Re: /usr/bin/python2 shebangs Thomas Goirand <zigo@debian.org> - 2016-11-09 17:10 +0100
                  Re: /usr/bin/python2 shebangs Paul Wise <pabs@debian.org> - 2016-11-10 03:40 +0100

#8957 — /usr/bin/python2 shebangs

[Multipart message — attachments visible in raw view] — view raw

Over in #834193, a user is asking for a /usr/bin/pip2 to mirror /usr/bin/pip
because some uses cases apparently prefer pip2 over pip.  That seems like a
reasonable request on the face of it, and easy to support.

However, I thought, well why not shebang pip2 to /usr/bin/python2 because 1)
it would parallel the script name; 2) I do think it would be in our best long
term interest to start shebanging system scripts explicitly with python3 or
python2 as appropriate.  Yes, I know that we don't intend to make
/usr/bin/python be Python 3 any time soon, but maybe someday we'll change our
minds and PEP 394 will embrace that strategy across Linux distros.

In any case, it produces a mild lintian complaint:

E: python-pip: python-script-but-no-python-dep usr/bin/pip2

Of course the /usr/bin/python shebanged /usr/bin/pip doesn't produce that
warning, and the package's Depends properly has ${python:Depends}.  I think
lintian is wrong, but I'd like to hear any other opinions.

Cheers,
-Barry

[toc] | [next] | [standalone]

#8958

On November 1, 2016 10:28:01 AM EDT, Barry Warsaw <barry@debian.org> wrote:
>Over in #834193, a user is asking for a /usr/bin/pip2 to mirror
>/usr/bin/pip
>because some uses cases apparently prefer pip2 over pip.  That seems
>like a
>reasonable request on the face of it, and easy to support.
>
>However, I thought, well why not shebang pip2 to /usr/bin/python2
>because 1)
>it would parallel the script name; 2) I do think it would be in our
>best long
>term interest to start shebanging system scripts explicitly with
>python3 or
>python2 as appropriate.  Yes, I know that we don't intend to make
>/usr/bin/python be Python 3 any time soon, but maybe someday we'll
>change our
>minds and PEP 394 will embrace that strategy across Linux distros.
>
>In any case, it produces a mild lintian complaint:
>
>E: python-pip: python-script-but-no-python-dep usr/bin/pip2
>
>Of course the /usr/bin/python shebanged /usr/bin/pip doesn't produce
>that
>warning, and the package's Depends properly has ${python:Depends}.  I
>think
>lintian is wrong, but I'd like to hear any other opinions.

I don't think /usr/bin/python should ever point to a python3 version.  It should be dropped when python2.7 is removed.  I think the existence of /usr/bin/python2 is a limited to a work around for a specific distros insanity.  There's no need to encourage it's use in Debian as that particular insanity hasn't and won't (as long as I'm a python*-defaults co-maintainer).

Scott K

P.S. But I think you already knew how I feel about it.  ;-)

[toc] | [prev] | [next] | [standalone]

#8960

On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote:

>I don't think /usr/bin/python should ever point to a python3 version.  It
>should be dropped when python2.7 is removed.  I think the existence of
>/usr/bin/python2 is a limited to a work around for a specific distros
>insanity.  There's no need to encourage it's use in Debian as that particular
>insanity hasn't and won't (as long as I'm a python*-defaults co-maintainer).
>
>P.S. But I think you already knew how I feel about it.  ;-)

Oh yes, I knew. :)

Okay, so you don't think we should ever shebang scripts to /usr/bin/python2.
Maybe lintian should warn specifically against that then?

(I still think /usr/bin/python2 is the better long term path, but I don't feel
strongly enough about it to advocate a formal transition.)

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8961

On Tuesday, November 01, 2016 05:14:21 PM Barry Warsaw wrote:
> On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote:
> >I don't think /usr/bin/python should ever point to a python3 version.  It
> >should be dropped when python2.7 is removed.  I think the existence of
> >/usr/bin/python2 is a limited to a work around for a specific distros
> >insanity.  There's no need to encourage it's use in Debian as that
> >particular insanity hasn't and won't (as long as I'm a python*-defaults
> >co-maintainer).
> >
> >P.S. But I think you already knew how I feel about it.  ;-)
> 
> Oh yes, I knew. :)
> 
> Okay, so you don't think we should ever shebang scripts to /usr/bin/python2.
> Maybe lintian should warn specifically against that then?
> 
> (I still think /usr/bin/python2 is the better long term path, but I don't
> feel strongly enough about it to advocate a formal transition.)
> 
> Cheers,
> -Barry

Given that we provide /usr/bin/python2 in all supported releases, I don't 
think it's use is actively harmful, but neither do I think should it be any 
kind of goal.

Even after python2.7 is removed from Debian, there will still be users who 
keep a local copy because they couldn't migrate things due to $REASONS.  Re-
using /usr/bin/python for a python3 version won't accomplish anything more 
than gratuitously break such setups.

While Debian has a technically proficient, capable user base that can work 
through all kinds of issues associated with local requirements, I don't think 
we should make it any harder than necessary.

Scott K

[toc] | [prev] | [next] | [standalone]

#8962

[Multipart message — attachments visible in raw view] — view raw

> On Nov 1, 2016, at 6:03 PM, Scott Kitterman <debian@kitterman.com> wrote:
> 
> Even after python2.7 is removed from Debian, there will still be users who 
> keep a local copy because they couldn't migrate things due to $REASONS.  Re-
> using /usr/bin/python for a python3 version won't accomplish anything more 
> than gratuitously break such setups.


/usr/bin/python3 being Python 4.x is a bit weird though, and it’s likely that Python 4.x is not going to be another break the world release.

—
Donald Stufft

[toc] | [prev] | [next] | [standalone]

#8964

On November 1, 2016 8:43:50 PM EDT, Donald Stufft <donald@stufft.io> wrote:
>
>> On Nov 1, 2016, at 6:03 PM, Scott Kitterman <debian@kitterman.com>
>wrote:
>> 
>> Even after python2.7 is removed from Debian, there will still be
>users who 
>> keep a local copy because they couldn't migrate things due to
>$REASONS.  Re-
>> using /usr/bin/python for a python3 version won't accomplish anything
>more 
>> than gratuitously break such setups.
>
>
>/usr/bin/python3 being Python 4.x is a bit weird though, and it’s
>likely that Python 4.x is not going to be another break the world
>release.

It's true that it's less pretty to ditch /usr/bin/python, but I'll take the slightly uglier approach if it keeps local python installs from breaking.  YMMV.

Scott K

[toc] | [prev] | [next] | [standalone]

#8966 — Python 4 and ‘python3’ (was: /usr/bin/python2 shebangs)

Donald Stufft <donald@stufft.io> writes:

> /usr/bin/python3 being Python 4.x is a bit weird though

Seriously? Who is proposing that?

> and it’s likely that Python 4.x is not going to be another break the
> world release.

Certainly the command ‘python3’ should only ever point to the Python 3
interpreter.

If upstream ever releases a “Python 4” but expects the interpreter for
that to also be named ‘python3’, I think we can declare upstream to be
directly courting user pain, and secede on behalf of our users.

-- 
 \        “[It's] best to confuse only one issue at a time.” —Brian W. |
  `\  Kernighan, Dennis M. Ritchie, _The C programming language_, 1988 |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8968 — Re: Python 4 and ‘python3’ (was: /usr/bin/python2 shebangs)

On Nov 02, 2016, at 01:57 PM, Ben Finney wrote:

>Donald Stufft <donald@stufft.io> writes:
>
>> /usr/bin/python3 being Python 4.x is a bit weird though  
>
>Seriously? Who is proposing that?
>
>> and it’s likely that Python 4.x is not going to be another break the
>> world release.  
>
>Certainly the command ‘python3’ should only ever point to the Python 3
>interpreter.
>
>If upstream ever releases a “Python 4” but expects the interpreter for
>that to also be named ‘python3’, I think we can declare upstream to be
>directly courting user pain, and secede on behalf of our users.

I wouldn't at all be surprised if /usr/bin/python is reclaimed for some future
post-Python2-demise Python 4 interpreter.  It might even be a good thing since
I'm not sure I'd want a /usr/bin/python4.

Not that I'm expecting Python 4 any time soon, but if Larry Hasting's
gilectomy work actually pans out, that'd be a solid contender for it.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8969 — Re: Python 4 and ‘python3’

Barry Warsaw <barry@debian.org> writes:

> On Nov 02, 2016, at 01:57 PM, Ben Finney wrote:
>
> >Certainly the command ‘python3’ should only ever point to the Python
> >3 interpreter.
> >
> >If upstream ever releases a “Python 4” but expects the interpreter
> >for that to also be named ‘python3’, I think we can declare upstream
> >to be directly courting user pain, and secede on behalf of our users.
>
> I wouldn't at all be surprised if /usr/bin/python is reclaimed for
> some future post-Python2-demise Python 4 interpreter. It might even be
> a good thing since I'm not sure I'd want a /usr/bin/python4.

What about a Python 4.0 that is just “the release that comes after 3.9”?

    <URL:http://www.curiousefficiency.org/posts/2014/08/python-4000.html>

Such a “Python 4.0” release would inevitably be referred to as Python 4,
and inevitably will be considered *not the same* as ‘/usr/bin/python3’.

That's what I'm saying is pointless user confusion: do we use
‘/usr/bin/python3’ for the interpreter? Do we use ‘/usr/bin/python4’?
Why, if they're deliberately compatible interpreters — indeed, they may
be the *same* interpreter?

Such a thoroughly, and persistently, confusing state of affairs is
entirely avoidable (just use Semantic Versioning, don't name it “4.0”
until it's backward-incompatible with all “3.xx”). I had thought that
was the sane and prevailing attitude of the Python release managers.

But the above post implies that pointless confusion will be directly
courted, merely because of some aesthetic objection to a two-digit
component in the version string.

> Not that I'm expecting Python 4 any time soon […]

At the current rate of Python releases, it's not very far in the future
before the Python release managers must decide what the version string
for “the release that comes after 3.9” will be.

Is there anyone seriously courting the idea that “Python 4.0 is part of
the Python 3 line”? I would hope not, yet the above post implies it. Can
that be quashed decisively?

-- 
 \        “If you go parachuting, and your parachute doesn't open, and |
  `\        you friends are all watching you fall, I think a funny gag |
_o__)             would be to pretend you were swimming.” —Jack Handey |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8970 — Re: Python 4 and ‘python3’

Don't panic. :)

On Nov 03, 2016, at 09:28 AM, Ben Finney wrote:

>But the above post implies that pointless confusion will be directly
>courted, merely because of some aesthetic objection to a two-digit
>component in the version string.

Those are Nick's opinions.  Everyone's got one!

AFAIK, there is *no* official declaration (e.g. from Guido or the mythical
Python 4 release manager) about this either way.

>At the current rate of Python releases, it's not very far in the future
>before the Python release managers must decide what the version string
>for “the release that comes after 3.9” will be.

We're up to Python 2.7.12 so the double digit version component ship has
sailed and it wasn't all that Y2K-y, so I doubt there will be a hard and fast
prohibition against 3.10.  Even if there is, we won't see a possible 3.10
until 2022 if I'm doing my math correctly and we stick to the roughly 18 month
release cycle.

I predict that when the time comes, it'll generate a gigathread's worth of
discussion, 3 or 4 competing PEPs, and then Guido will just pronounce.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8972 — Re: Python 4 and ‘python3’

Barry Warsaw <barry@debian.org> writes:

> AFAIK, there is *no* official declaration (e.g. from Guido or the
> mythical Python 4 release manager) about this either way.

In support of your position, Guido van Rossum has informally implied
version “3.10” is feasible for a future Python 3
<URL:https://twitter.com/gvanrossum/status/583346987925278720>.

I had thought GvR expressed a distaste for Semantic Versioning but can't
find it now.

So, yes, my panic is lessened :-)

> I predict that when the time comes, it'll generate a gigathread's
> worth of discussion, 3 or 4 competing PEPs, and then Guido will just
> pronounce.

Hopefully, informed by reasoned argument about consequences, more than
aesthetic preferences of a small group (I'm still sore about the process
evidenced in the Python VCS decisions, so don't wholly trust this will
be better).

-- 
 \        “With Lisp or Forth, a master programmer has unlimited power |
  `\     and expressiveness. With Python, even a regular guy can reach |
_o__)                               for the stars.” —Raymond Hettinger |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#8984

On 11/01/2016 11:03 PM, Scott Kitterman wrote:
> On Tuesday, November 01, 2016 05:14:21 PM Barry Warsaw wrote:
>> On Nov 01, 2016, at 11:34 AM, Scott Kitterman wrote:
>>> I don't think /usr/bin/python should ever point to a python3 version.  It
>>> should be dropped when python2.7 is removed.  I think the existence of
>>> /usr/bin/python2 is a limited to a work around for a specific distros
>>> insanity.  There's no need to encourage it's use in Debian as that
>>> particular insanity hasn't and won't (as long as I'm a python*-defaults
>>> co-maintainer).
>>>
>>> P.S. But I think you already knew how I feel about it.  ;-)
>>
>> Oh yes, I knew. :)
>>
>> Okay, so you don't think we should ever shebang scripts to /usr/bin/python2.
>> Maybe lintian should warn specifically against that then?
>>
>> (I still think /usr/bin/python2 is the better long term path, but I don't
>> feel strongly enough about it to advocate a formal transition.)
>>
>> Cheers,
>> -Barry
> 
> Given that we provide /usr/bin/python2 in all supported releases, I don't 
> think it's use is actively harmful, but neither do I think should it be any 
> kind of goal.
> 
> Even after python2.7 is removed from Debian, there will still be users who 
> keep a local copy because they couldn't migrate things due to $REASONS.  Re-
> using /usr/bin/python for a python3 version won't accomplish anything more 
> than gratuitously break such setups.

It does serve the purpose of providing /usr/bin/python for upstream
source which works with Python 3 and use #!/usr/bin/python (if they
don't care if the python version is 2 or 3, that's what IMO they should
rightly do).

So, I don't agree with you, and believe that gradually using
#!/usr/bin/python2 is a good approach to the transition. IMO, that's
what we should start doing as much as possible.

If the dependencies for Python itself aren't calculated well with that
shebang, then we should address that to make it right regardless of this
choice.

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#8985

On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote:

>So, I don't agree with you, and believe that gradually using
>#!/usr/bin/python2 is a good approach to the transition. IMO, that's
>what we should start doing as much as possible.
>
>If the dependencies for Python itself aren't calculated well with that
>shebang, then we should address that to make it right regardless of this
>choice.

Clearly we won't do anything for Stretch, but we should consider this for
Buster.

Cheers,
-Barry

[toc] | [prev] | [next] | [standalone]

#8987

On Monday, November 07, 2016 10:08:25 AM Barry Warsaw wrote:
> On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote:
> >So, I don't agree with you, and believe that gradually using
> >#!/usr/bin/python2 is a good approach to the transition. IMO, that's
> >what we should start doing as much as possible.
> >
> >If the dependencies for Python itself aren't calculated well with that
> >shebang, then we should address that to make it right regardless of this
> >choice.
> 
> Clearly we won't do anything for Stretch, but we should consider this for
> Buster.

I think Thomas' point is valid for upstream work, but it's just wasted effort 
in Debian.

Scott K

[toc] | [prev] | [next] | [standalone]

#8996

On 11/07/2016 04:21 PM, Scott Kitterman wrote:
> On Monday, November 07, 2016 10:08:25 AM Barry Warsaw wrote:
>> On Nov 07, 2016, at 11:44 AM, Thomas Goirand wrote:
>>> So, I don't agree with you, and believe that gradually using
>>> #!/usr/bin/python2 is a good approach to the transition. IMO, that's
>>> what we should start doing as much as possible.
>>>
>>> If the dependencies for Python itself aren't calculated well with that
>>> shebang, then we should address that to make it right regardless of this
>>> choice.
>>
>> Clearly we won't do anything for Stretch, but we should consider this for
>> Buster.
> 
> I think Thomas' point is valid for upstream work, but it's just wasted effort 
> in Debian.
> 
> Scott K

The point is, some people also use venvs. In a world of Python 3 only,
some upstream will continue to use /usr/bin/python (IMO, rightly). We
should be able to provide a default implementation for these scripts.

Probably the use of update-alternatives, with carefully crafted
priorities, is the way to go (ie: provide /usr/bin/python as python2
with higher priority, but let Python 3 also provide /usr/bin/python if
Python 2 isn't installed).

Cheers,

Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#8999

On Thu, Nov 10, 2016 at 12:02 AM, Thomas Goirand wrote:

> The point is, some people also use venvs. In a world of Python 3 only,
> some upstream will continue to use /usr/bin/python (IMO, rightly). We
> should be able to provide a default implementation for these scripts.

I think this is a bug in virtualenv:

$ virtualenv -p /usr/bin/python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/pabs/test/bin/python3
Also creating executable in /home/pabs/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
$ virtualenv -p python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/pabs/test/bin/python3
Also creating executable in /home/pabs/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web