23

So I have read this - https://wiki.archlinux.org/index.php/Python

And it is clear from this wiki that I can install Python 2.7.2 via 

pacman -S python2

Is it reasonable for me to create a symlink to python2

ln -s python2 /usr/bin/python

if I don't forsee myself switching to python 3.0 any time soon? Or is there a better way of managing multiple python versions like what I usually use on a debian system (update-alternatives --config python) or on a mac os x system (python select)?

CLARIFICATION:

  • What I am trying to find out is - what is the "best practice" of managing various python versions on an archlinux system?
  • I am new to archlinux but familiar with ubuntu, debian and mac os x
Calvin Cheng
  • 35,640
  • 39
  • 116
  • 167

7 Answers7

14

I would argue you shouldn't create any symlinks like this at all. Especially if you are going to distribute some of your python code, you should not assume a user has python2 or python3 at /usr/bin/python.

If your script requires python2, just use:

#!/usr/bin/env python2

If your script requires python3, use:

#!/usr/bin/env python3

This way your scripts will work fine even through updates to Python. It will also be much more clear what version your script actually needs.

houbysoft
  • 32,532
  • 24
  • 103
  • 156
  • Note that it's not called python2 except of archlinux, and it's not called python3 on archlinux. ;-) Executable scripts in general need to be installed with something like distutils or similar, which you run with the python interpreter that you want it installed for, though. – Lennart Regebro Sep 05 '11 at 05:15
  • (In fact, specifying python2.6 or python3.2 is generally a good idea, and avoid the archlinux problem). – Lennart Regebro Sep 05 '11 at 06:06
  • 1
    @Lennart: yes it is called python3. pacman -Qo /usr/bin/python3 : `/usr/bin/python3 is owned by python 3.2.1-1`. – houbysoft Sep 05 '11 at 13:26
  • OK, good, they have python3 as well as just python. Still, /usr/bin/python2 is unusual outside of archlinux. – Lennart Regebro Sep 05 '11 at 14:31
  • 14
    There is a lot of misinformation flying around here, this answer is entirely correct. [PEP-394](http://www.python.org/dev/peps/pep-0394/) is very clear. All unix-like systems should point `python2` to a version of 2.x, and `python3` to a version of 3.x, with `python` pointing to either of them at the distro's discretion. Arch is a bleeding edge distro, it is following the PEP perfectly. – Gareth Latty Apr 22 '13 at 16:34
6

There is a nice project on github what helps you with it's called pyenv What helps you to manage multiple python instances

Azd325
  • 5,752
  • 5
  • 34
  • 57
6

Most unices already have a /usr/bin/python. Overwriting that one is a bad idea, as this is the Python version used by all packages in the system, and changing that one may break them. When installing the Python 2.7 package the executable should be installed as /usr/bin/python2.7 (if not I would claim Archlinux is broken) and it's better to use that when you want to run Python 2.7.

Archlinux is a bit special, since it will use /usr/bin/python for Python 3, despite the default executable name for Python 3 being /usr/bin/python3. This is confusing and can be seen as a bug, but it does mean you can't use that symlink for Python 2, as any other Archlinux script that uses Python 3 will almost certainly break if you do.

So where on other Unices, symlinking /usr/bin/python to Python 2.7 is a bad idea, on Archlinux it is a terrible idea. Instead just install all version you need and call them with /usr/bin/pythonX.X.

Lennart Regebro
  • 167,292
  • 41
  • 224
  • 251
  • I am using a minimal install of archlinux so it's almost starting from scratch. – Calvin Cheng Sep 04 '11 at 06:35
  • No, there is no other (official) package that contains the `/usr/bin/python` symlink as this would result in a conflict when you try to install both packages. – Julian Sep 04 '11 at 16:21
  • @Julian "No other"? The package in question does not contain that symlink. Reasonably, some other package might contain it. – Lennart Regebro Sep 04 '11 at 18:40
  • @calvinx: I'm surprised the Python-package doesn't install that symlink itself in that case. In any case, Python 2.7 should be installed as /usr/bin/python2.7. If there is no /usr/bin/python symlink, you can probably create one to /usr/bin/python2.7 without any problems. – Lennart Regebro Sep 04 '11 at 18:42
  • @Lennart Regebro Sure it is in the python package: # pacman -Qo /usr/bin/python /usr/bin/python is owned by python 3.2.1-1 – Julian Sep 04 '11 at 18:44
  • @Lennart Regebro This is not a bug, why should it? – Julian Sep 04 '11 at 18:51
  • @Julian: Because the default executable name for Python 3 is python3, for reasons of compatibility. When I googled this I also found tons of blog posts and complaints about it, so you can do it as well to get more detailed arguments. But, thanks for the clarification, I'll update the answer – Lennart Regebro Sep 05 '11 at 05:13
  • @Lennart Regebro People complaining doesn't equal to a bug. Also [the Python 3 documentation](http://docs.python.org/py3k/using/unix.html#python-related-paths-and-files) says that `${exec_prefix}/bin/python` is the recommended interpreter location. – Julian Sep 05 '11 at 05:23
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/3160/discussion-between-julian-and-lennart-regebro) – Julian Sep 05 '11 at 05:23
  • I was hoping that the arch guys would at least permit us end users of arch to choose whether /usr/bin/python should be python2 or python3 instead of "forcing" us to use python3 by default... Anyway, thanks for the answers guys. – Calvin Cheng Sep 06 '11 at 03:17
  • 4
    I don't like this answer, [the PEP](http://www.python.org/dev/peps/pep-0394/) is quite clear - `python2` is some version of 2.x, `python3` is some version of 3.x, and `python` will give you either 2 or 3, with no guarantee. Arch is following the Python convention perfectly, it is definitely not a bug. – Gareth Latty Apr 22 '13 at 16:32
3

As others have said, the short answer is "don't do this, it will most likely break things on your system", however, if you mostly use Python 2 you can still set your personal default in your shell (and still have the option of switching to Python 3 at any time). To do this, first become root and install python2-virtualenv:

# pacman -S python2-virtualenv

Then create a virtual environment that uses Python 2 (this will automatically install Python, setuptools, wheel, and pip in the environment):

$ virtualenv -p /usr/bin/python2 --system-site-packages ~/env # (Or wherever you want your environment to live)

If you only want to use locally installed packages (eg. packages you install with pip and not the ones installed by pacman) remove the --system-site-packages option when creating your environment.

Now in your ~/.bash_profile or ~/.profile (or whatever your preferred shells configuration file is), set something like the following:\

source ~/env/bin/activate

This will activate the virtual environment, making your default version Python 2.

This could still break anything that is launched in a shell, but it's not likely that anything will be unless you're explicitly running it from a shell, at which point you can turn the virtual environment off by running:

deactivate

or simply manually run Python 3.

Sam Whited
  • 6,880
  • 2
  • 31
  • 37
1

I just stumbled over this post, no necro-bumping intended but I was wondering nobody mentioned virtualenvs. I'm using ArchLinux as well and I use the python packages virtualenv and virtualenvwrapper to create multiple python environments. You can reference to the python 2 or python3 binaries in /usr/bin/ to determine the python version used in the virtual environment.

The benefit is that packages installed in a virtual environment don't mess with the python the system is using and there are many ways to automate project handling.

IlikePepsi
  • 645
  • 1
  • 8
  • 18
1

I know this may be a very old answer, but it took me two days to solve the problem so I'm going to share.

The proper way to manage python versions in your system to work on different projects without them driving you crazy is to use pyenv and its plugins pyenv-virtualenv and pyenv-virtualenvwrapper as described by Henrique Bastos into this blog post. Notice that this way to work is kinda platform independent, since pyenv is a python package and it can be run quite similarly on Windows, Linux and Mac OSx.

The problems start with Arch Linux. The OS doesn't provide a pacman version of pyenv, so you have to install it cloning it from github as described in the installation section of the release. The installation process is the same both for pyenv-virtualenv and pyenv-virtualenvwrapper. Notice that the shell initialization configuration may be different, in my case it didn't work for ~/.bash_profile, but worked for ~/.bashrc .

Running pyenv is not straightforward if your installation is very fresh like the one I'm setting up in these days, since pip requires openSSL and even if you install it via pacman, pyenv doesn't see it. So, if you want to install an older version of Python (namely 3.4.3), you will find the shell complaining about you haven't installed the openSSL plugin, even if you have it. To be honest, I didn't have the right packages the first time I tried to install it; you have to download the following packages

sudo pacman -S openssl
sudo pacman -S openssl-1.0
sudo pacman -S python-pyopenssl
sudo pacman -S python2-pyopenssl

The way I solved the problem is to add the flags as described in the pyenv installation FAQs: that solution eventually led me to install the python version I wanted:

LDFLAGS="-L/usr/lib/openssl-1.0" \
CFLAGS="-I/usr/include/openssl-1.0" \
pyenv install -v 3.4.3

To avoid to go on the FAQs page everytime you want to renew the python installation environment, you can add an alias in ~/.bashrc or whatever is you shell as follows:

echo alias pyenv='LDFLAGS="-L/usr/lib/openssl-1.0" \
    CFLAGS="-I/usr/include/openssl-1.0" \
    pyenv' >> ~/.bashrc

In this way you can install python properly with a clean pyenv syntax, and manage it via its plugins in the same way (since the syntax is pyenv [COMMAND] [OTHERSTUFF]).

dteod
  • 195
  • 4
0

No, there is no better way to do this. The python symlink is part of the Python 3 package.

I guess changing this link won't break anything for now but it might be possible that some packages will depend on it in the future.

Julian
  • 2,051
  • 2
  • 22
  • 30