Re: dh_python3 sets shebang to Python 2 -- is this a bug?

2020-01-23 Thread Matthias Klose
On 22.01.20 02:18, Nicholas D Steeves wrote:
> I don't think this is an assumption.  Debian adheres to PEP 394, which
> until recently said that /usr/bin/python is supposed to be Python 2, for
> backwards compatibility.  When I discovered this I felt increased trust
> in Debian and its developers for doing the sensible and standardised
> thing, rather than what some other distributions have done.  To everyone
> involved, thank you!  This also made me proud to be part of such a
> community :-)

well, looking a few years forward, Debian will be the only system not providing
a python command, incompatible with everybody else.  New users will not
understand that Debian doesn't have a python command when there's no Python2
anymore.

What we will do is to get rid off the unversioned python for all the packaging
in the archive, so that users can do what they want.

Matthias



Re: dh_python3 sets shebang to Python 2 -- is this a bug?

2020-01-21 Thread Nicholas D Steeves
Hi,

Andreas Henriksson  writes:

> I've personally seen some upstream use 'python' in shebang with the
> intention of meaning 'works with either python2 or python3',

Yes, this has worked thus far, and it will definitely work in cases where
`which python` is a symlink to python3 within a virtual environment.

>  but in debian it seems people have always assumed unversioned
> (/usr/bin/)python always means python *2*.

I don't think this is an assumption.  Debian adheres to PEP 394, which
until recently said that /usr/bin/python is supposed to be Python 2, for
backwards compatibility.  When I discovered this I felt increased trust
in Debian and its developers for doing the sensible and standardised
thing, rather than what some other distributions have done.  To everyone
involved, thank you!  This also made me proud to be part of such a
community :-)

  https://www.python.org/dev/peps/pep-0394/

I believe that it was on 26-Jun-2019 of this year that PEP 394 was
modified to allow /usr/bin/python to be py3, because py2 EOL frees
up this path.  IMHO that change was premature and should have been
deferred until the actual EOL.

> I guess the tools are written in the latter sense here, rewriting the
> shebang from python -> python2 explicitly unless you override it
>

Yeah, this is a tricky point.  Per PEP 394 (until py2 EOL), this is the
correct approach, but now it may make more sense to change this to
"python -> python3", because if this breaks a package, tough luck, we're
in a python3-only world.  eg: packages in the archive should already
have the shebang override, and NEW py2 packages will be rejected by
ftpmasters.

Cheers,
Nicholas


signature.asc
Description: PGP signature


Re: dh_python3 sets shebang to Python 2 -- is this a bug?

2020-01-20 Thread Christian Kastner
Hi Andreas!

On 20.01.20 17:40, Andreas Henriksson wrote:
> On Mon, Jan 20, 2020 at 08:51:56AM +0100, Christian Kastner wrote:
> I've personally seen some upstream use 'python' in shebang with the
> intention of meaning 'works with either python2 or python3', but in
> debian it seems people have always assumed unversioned
> (/usr/bin/)python always means python *2*.
> I guess the tools are written in the latter sense here, rewriting the
> shebang from python -> python2 explicitly unless you override it

That's the plausible explanation... it just felt odd to see this is an
pure Python 3 package.

> You should note that if you know the code is actually python-version
> agnostic you should be able to fix this by setting the shebang
> explicitly by using:
> https://sources.debian.org/src/dh-python/4.20191017/dh_python3/#L122
> 
> eg. in debian/rules use: export DH_OPTIONS=--shebang=/usr/bin/python3 

That worked, thanks!

>> Furthermore, the package does not list any Python 2 build dependencies,
>> and all binary package dependencies are generated by the
>> ${python3:Depends} substvar. Could this perhaps be worth an "if the
>> package does not have Python 2 dependencies, a Python 2 shebang is a
>> bug" lintian check?
> 
> Having some safety-net in place here would likely be a good idea because
> I understand how this could easily be missed otherwise.

Let's see if anyone else has something contradictory to add... else,
I'll file the wishlist bug.

Christian