On 23 January 2015 at 22:07, Martti Kühne wrote:

On Fri, Jan 23, 2015 at 2:51 PM, Chi Hsuan Yen wrote:

...

Dear Arch enthusiasts,

The package extra/java-runtime-common provides a convenient script archlinux-java to handle co-existing JDK/JRE versions. I can use it to switch between different versions of java implementations to accomplish numerous tasks from testing the compatibilities of my programs to running third party applications targeting on different platforms. Now I hope there's also a simple script for the same thing but for python. On the

Python actively encourages you to write the python shebang explicitly either #!/usr/bin/env python2 or #!/usr/bin/env python3 for scripts that are not compatible with one of them. It is no longer practical to make any assumptions about the python version in the (unversioned) python binary, therefore your argument about java doesn't hold. Since the developers themselves support this conclusion [0], there is no reason to still have the symlink and hence we should actually abolish it completely, which I expect to happen in the long run.

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

Alright. Thanks a lot for the information!

On Fri, Jan 23, 2015 at 8:07 AM, Martti Kühne wrote:

Python actively encourages you to write the python shebang explicitly either #!/usr/bin/env python2 or #!/usr/bin/env python3 for scripts that are not compatible with one of them. It is no longer practical to make any assumptions about the python version in the (unversioned) python binary, therefore your argument about java doesn't hold. Since the developers themselves support this conclusion [0], there is no reason to still have the symlink and hence we should actually abolish it completely, which I expect to happen in the long run.

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

Actually, I believe the default /usr/bin/python symlink makes sense to have, in order to be used for python scripts that don't care which python they use. Let us assume someone has only python3 or python2, does it make sense to prevent people from using polyglot code simply because an arbitrary decision was made to assume one or the other is the official python version to run the code under? -- Eli Schwartz

On Fri, Jan 23, 2015 at 12:42 PM, Chi Hsuan Yen wrote:

I mean, all python scripts should explicitly specify which python version to use rather than "python" only. However, the system default symlink is still necessary for invoking scripts. A system should provide a simple and stupid way for python users without enforcing the knownledge of different python versions. As python evolves, end users can still invoke python scripts without change their command lines. After all, such settings can provide a continuous and reliable environment. I need this workaround due to the convenience for building CyanogenMod. The correct way may be submit a bug report to Google, but, however, it's too long to get them all be fixed.

Well, in the meantime you can do what the PKGBUILDs do, and use sed -i 's:\(env[ ]\+python$\|/usr/bin/python$\):\12:g' to fix the shebangs automatically for each file needed. You can simply apply that to all *.py files, or if some of them specifically need python3 you can make a list of them and exclude them/add python3 to them. Obviously, the long-term goal should be to get that done as an upstream bugfix. -- Eli Schwartz

Borja Thanks a lot for the information. This is exactly what I want. However, as Martti states, I hope such workarounds are not necessary anymore as soon as possible. On 24 January 2015 at 00:57, Borja wrote:

Does this .bashrc hack for for you maybe? :-)

## Toogle between python versions python-toggle(){

local RED="\e[0;31m" local GREEN="\e[0;32m" local RESET="\e[0;0m"

test -z "$1" || v="$1" local bins=('python' 'python-config' 'pip') cd /usr/bin for bin in ${bins[@]}; do test -h $bin || { echo -e "${RED}ERROR:${RESET} cannot find $PWD/$bin" return 1 } done echo -e ">> ${RED}Disabling $(python -V 2>&1)${RESET}\007" if [[ python -ef python3 || "python${v}" == "python3" ]]; then rm python python-config pip ln -s python2 python ln -s python2-config python-config ln -s pip2 pip elif [[ python -ef python2 || "python${v}" == "python2" ]]; then rm python python-config pip ln -s python3 python ln -s python3-config python-config ln -s pip3 pip else echo -e "${RED}ERROR:${RESET} cannot find link /usr/bin/$bin" cd - > /dev/null return 2 fi echo -e ">> ${GREEN}Enabled $(python -V 2>&1)${RESET}\007" cd - > /dev/null }

...

Dear Arch enthusiasts,

The package extra/java-runtime-common provides a convenient script archlinux-java to handle co-existing JDK/JRE versions. I can use it to switch between different versions of java implementations to accomplish numerous tasks from testing the compatibilities of my programs to running third party applications targeting on different platforms. Now I hope there's also a simple script for the same thing but for python. On the system, most of the scripts are written for python2 and some other

...

are python3-specific. In most cases it's not a problem because I can fix the scripts or use some tricks like $PATH to ensure the correct execution of the programs. However, in large projects, doing either is time-consuming and costly. Recently I'm building CyanogenMod on Arch Linux. It includes lots of python scripts in the build system, and most of them requires python2. Using the tip provided on the article about Python on ArchWiki prevents lots of problems, but, however, some scripts have the shebang

El vie, 23-01-2015 a las 21:51 +0800, Chi Hsuan Yen escribió: scripts line

...

"#!/usr/bin/env python" or are invoked by some command like "/usr/bin/python ...". I have to change the link /usr/bin/python to pointing to python2 for further progress on building and changed it back for my daily use. If there's an archlinux-python script, lots of time on battling the difference between python2 and python3 does not exist anymore, which I believe lots of users can benefit from it. Any ideas?

Best Regards,

Yen Chi Hsuan

--

======================================================================

GPG 0x8C00BA074CA6E08B -- https://www.libcrack.so/