Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
> This makes no sense, /usr/bin/python is usually the linked to the binary of > the default python version in use on distros, so hardcoding the version makes > no sense. That is a common misconception. While some distros went ahead and switched `/usr/bin/python` to Python 3, most notably Arch Linux, most are keeping it pointing to Python 2 and will continue to do so at least until Python 2 EOL in 2020. Upstream Python issued a recommendation to that effect as well: [PEP 394 -- The "python" Command on Unix-Like Systems](https://www.python.org/dev/peps/pep-0394/#abstract) So while most distros that will be using the latest RPM already switched to Python 3 being default, the binary `/usr/bin/python` still points to Python 2. That means that most distros will need to patch this shebang to `/usr/bin/python3` before deploying. I propose that we switch the shebang to explicitly Python 3 by default. There possibly might be some distros that will be using the latest RPM version but still haven't switched to Python 3 being default (and they will need to patch this shebang back to Python 2), but I'd wager it will be a minuscule number compared to Python 3–default distros. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299131961___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Triple operator for conditional shortcut (#115)
I do not see any possibility how to define sensible syntax of the triple operator, without possible causing problems for macros %{?condition:true} and %{!?condition:false}. Thus I think that adding this macro without additional changes is not a good idea. The syntax of the macro should start "%{?condition:" or "%{!?condition:" But then there is a problem with next separator operator: E.g if we define syntax %{?condition:true!false}, where separator operator is the first '!' after ':', which is not nested in {} or in () it will change interpretation of macros like %{?write_errors: You did not respond! It is a mistake.} which will change from its original meaning if "write_errors" is defined, then write "You did not respond! It is a mistake." to if "write_errors" is defined, then write "You did not respond" else write " It is a mistake." If we change separator operator from "!" to another character it will not help us a lot. The mentioned type of mistake will still occur. The only characters which are different from rpm point of view are "{", "}", "(", ")". To use some of them is not a good choice too. The triple operator will look very weird and probably another type of problems occur. Similarly for a separator operator defined as a sequence of chars. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/115#issuecomment-299160206___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
First of all, while PEP 394 recommends this, it's not what's common practice amongst distros, where Arch not even being a RPM based distro makes it less relevant. I know of no rpm based distros where /usr/bin/python isn't pointing to the default python interpreter binary version. Also using shell aliases to set the default binary to use isn't really a good idea as these aliases are internal to the shell instance itself only in contrast to environment variables and paths. While python upstream plans to EOL python 2 in two years, distributions interest and priorities aren't the same. The usual approach is to either only keep python 2 around untill everything still depending on and not ported to py3k and/or at least not install any python2 packages by default, where if /usr/bin/python had to point to python2, that would leave one in a tricky situation if only python 3 is installed. However, if you really think this is a necessity (where forcing distros still using python2 to patch the shebang themself would be considered less acceptable than not adhering to PEP 394), the patch betlow would be the more proper way to achieve your goal. This one also ensures that this $PYTHON is used for both %__python and the python bindings as well. `` From 2ca7cc81357fc61fd017bae0cf3c109345224216 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Per=20=C3=98yvind=20Karlsen?= Date: Thu, 4 May 2017 14:30:54 +0200 Subject: [PATCH] allow to set default python interpreter with $PYTHON during ./configure --- configure.ac| 3 ++- python/setup.py.in | 2 +- scripts/{pythondistdeps.py => pythondistdeps.py.in} | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) rename scripts/{pythondistdeps.py => pythondistdeps.py.in} (99%) diff --git a/configure.ac b/configure.ac index b41a4c9..0f8c202 100644 --- a/configure.ac +++ b/configure.ac @@ -129,7 +129,7 @@ AC_MSG_CHECKING(old version of patch) AC_PATH_PROG(__PERL, perl, /usr/bin/perl, $MYPATH) AC_PATH_PROG(__PGP, pgp, /usr/bin/pgp, $MYPATH) -AC_PATH_PROG(__PYTHON, python, /usr/bin/python, $MYPATH) +AC_PATH_PROG(__PYTHON, [$PYTHON python], $PYTHON, [/usr/bin/python], $MYPATH) AC_PATH_PROG(__RM, rm, /bin/rm, $MYPATH) AC_PATH_PROG(__RSH, rsh, /usr/bin/rsh, $MYPATH) AC_PATH_PROG(__SED, sed, /bin/sed, $MYPATH) @@ -1016,5 +1016,6 @@ AC_CONFIG_FILES([Makefile tests/Makefile plugins/Makefile python/setup.py + scripts/pythondistdeps.py ]) AC_OUTPUT diff --git a/python/setup.py.in b/python/setup.py.in index 87c7358..534688b 100644 --- a/python/setup.py.in +++ b/python/setup.py.in @@ -1,4 +1,4 @@ -#!/usr/bin/env python +#!@__PYTHON@ from distutils.core import setup, Extension import subprocess diff --git a/scripts/pythondistdeps.py b/scripts/pythondistdeps.py.in similarity index 99% rename from scripts/pythondistdeps.py rename to scripts/pythondistdeps.py.in index 36590ba..408a1de 100755 --- a/scripts/pythondistdeps.py +++ b/scripts/pythondistdeps.py.in @@ -1,4 +1,4 @@ -#!/usr/bin/python3 +#!@__PYTHON@ # -*- coding: utf-8 -*- # # Copyright 2010 Per Øyvind Karlsen -- 2.10.2 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299175921___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Warningsfixes (#191)
I agree on the lua commit, although ignoring it in favour of PR #169 would prolly' be the favorable option. Could you merge just the first commit? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/191#issuecomment-299190653___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
> First of all, while PEP 394 recommends this, it's not what's common practice > amongst distros, where Arch not even being a RPM based distro makes it less > relevant. > > I know of no rpm based distros where /usr/bin/python isn't pointing to the > default python interpreter binary version. I've just checked and the following RPM-based distros are keeping with the upstream recommendation of keeping `/usr/bin/python` always pointing to Python 2 (and if Python 2 isn't installed then`/usr/bin/python` doesn't exist): * Fedora * RHEL * openSUSE * Mandriva (though here the container I found and tested was a bit old) I would argue that's a solid chunk of the RPM-based distros. > However, if you really think this is a necessity (where forcing distros still > using python2 to patch the shebang themself would be considered less > acceptable than not adhering to PEP 394), Right now the above distros are being forced to patch it. I think the burden of a patch should lie with the Python 2–only distros nowadays, this close to Python 2 EOL. > the patch betlow would be the more proper way to achieve your goal. > This one also ensures that this $PYTHON is used for both %__python and the > python bindings as well. The patch looks interesting, though I'm not nearly experienced enough with the RPM code base to vet it. My only suggestion would be to set the default to `/usr/bin/python3`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299224600___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
> Mandriva (though here the container I tested it on was a bit old) Welcome back to 2017, Mandriva is dead ;) Actually, in Fedora we should patch that to system-python.. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299235115___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
> Welcome back to 2017, Mandriva is dead ;) Ah, that explains it :) > Actually, in Fedora we should patch that to system-python.. Someone tried changing the shebang patch to `system-python`, but it had to be reverted back to Python 3 because the `pythondistdeps` needs `setuptools`, which `system-python` does not support. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299243649___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
>> Welcome back to 2017, Mandriva is dead ;) > Ah, that explains it :) Mageia is still here, and we follow PEP 394. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299249293___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
OpenMandriva uses python 3 as default, with /usr/bin/python pointing to python3. AFAIK Mageia doesn't intentionally follow PEP 394 as much as it rather hasn't switched to python3 as it's default yet, where ie. python packages prefixed with python- are python 2, while python 3 packages are prefixed with python3-... As distros completes their migration to python 3 and no python 2 package installed on system, any py3k compatible script from packages in distro using /usr/bin/python as shebang will be left broken, for which there surely are quite a few. PEP 394 doesn't take the flipped situation py3k compatible scripts with /usr/bin/python as shebang into reasonable enough consideration, where such scripts are already and growingly in majority. For old sys admin scripts, more realistic/sane scenarios would be for the sys admins running something non-cutting edge releases like RHEL/CentOS etc. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299258863___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Change the shebang of pythondistdeps.py to Python 3 (#212)
the philosophical discussion regarding is anyways rather moot, but the patch from my earlier comment should anyways be sufficient to address it properly. :) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/212#issuecomment-299267220___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint