Tuju,
Thanks for this heads-up.
That link you sent (below) has an additional line:
"For backwards compatibility, /usr/bin/python is, if it is
installed, a symbolic link to /usr/bin/python2."
For example, on one of my systems, there is:
$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 9 Apr 16 2018 /usr/bin/python -> python2.7*
$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Oct 25 2018 /usr/bin/python3 -> python3.6*
So, the user can set up those symbolic links so that the desired
python version is executed. Or, the user can change which python is
run by setting the `PATH` environment variable with the desired
python first on that list of paths.
Isn't that what we want?
But, if we use and generate the following line:
#!/usr/bin/env python3
Then that script will do the *wrong* thing for someone who wants to
run Python 2.
And, to make this a bit more confusing, here is a quote from PEP 394:
- In order to tolerate differences across platforms, all new code
that needs to invoke the Python interpreter should not specify
python, but rather should specify either python2 or python3 (or
the more specific python2.x and python3.x versions; see the
Migration Notes). This distinction should be made in shebangs,
when invoking from a shell script, when invoking via the system()
call, or when invoking in any other context.
- One exception to this is scripts that are deliberately written to
be source compatible with both Python 2.x and 3.x. Such scripts
may continue to use python on their shebang line. When packaging
software that is source compatible with both versions,
distributions may change such python shebangs to python3. This
ensures software is used with the latest version of Python
available, and it can remove a dependency on Python 2.
Generateds has been deliberately written to be source compatible
with both Python 2.7 and Python 3.x. So, ... ?
Dave
On Wed, May 29, 2019 at 01:46:27PM +0300, Juha Tuomala wrote:
>
> Looks like generated class-files have
>
> #!/usr/bin/env python
> # -*- coding: utf-8 -*-
>
> which in most systems equals to /usr/bin/python. That, however does not take
> into account which version system actually has - and is the generated file
> compatible with it.
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/
> #_multiple_python_runtimes
>
> Packages in Fedora MUST NOT use /usr/bin/python. Instead packages for Python
> 3
> MUST use /usr/bin/python3 (even if upstream supports both Python 2 and 3). As
> a result of that /usr/bin/python (as well as /usr/bin/env python and similar)
> MUST NOT be used in shebang lines or as a dependency of a package. As of
> Fedora 30, all uses of unversioned python executables in shebang lines will
> fail the build. These shebangs MUST be fixed. If it is necessary to disable
> the checks, please see the information in Shebang lines.
>
>
> which all makes sense. If the code is python3, why it's not defined in
> shebang? It should be.
>
> I think the whole versionless and env-shebang lines were used when there was
> no incompatible version migration going on. Now there is.
>
>
> Tuju
>
> --
> t...@iki.ee | http://tuju.ee | sip:t...@iki.ee | +3726311345 | +3725025337
> Better to have one, and not need it, than to need one and not have it.
>
>
--
Dave Kuhlman
http://www.davekuhlman.org
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
