Source
r/Python•
b-nut

Best way to install python?

If I want to always be able to have the latest/greatest python, and NOT have it collide with default system installation of python (on ubuntu or RHEL), what's the best way to do this? I dislike having the system default because it always lags way behind.

If I just install from source and put it in /usr/local, will it start putting libraries into some of the system default's lib directories? What about when the next version comes out? Should I just install it at /usr/local/python36 or something?

Also, I want to have various projects and make use of virtualenv, from my understanding it makes a copy of the python binary at that time, how will this work when I upgrade python?

Posted Apr 7, 2016, 6:07 PM UTC

08
dirn•

Have a look at pyenv. It lets you manage and switch between multiple versions of Python.

As long as you don't remove old versions when upgrading, existing virtual environments won't break.

2
b-nutOP•

This looks like it should be part of the equation here. I see that pyenv puts different python installs into its own location. I'm assuming as you do pip install, it will put the packages into that directory structure too.

I guess we'd also want to layer virtualenv on top of that.

1
ivosauruspip'ing it up•

It also has pyenv-virtualenv and pyenv-virtualenvwrapper to make working with both of those tools, in conjunction with pyenv, easier.

virtualenv, in the end, you can just issue-

$ virtualenv --python=pythonN.N envname

or with pyenv's virtualenv plugin installed-

$ pyenv virtualenv 2.7.11 envname

To be sure you're creating an env for a specific version you have installed.

1
pythoneeeer•

Personally, I add Felix Krull's "deadsnakes" repository, which has the latest 3.5.1. It lags official releases but not by much, and it's hugely convenient to be able to use my system package manager.

2
hell_0n_wheel•

One way to deal with defaults is update-alternatives.

Letting the default package manager (i.e. apt) sort things out, there won't be collisions in libraries. It'll just be the case that one needs to use a different command name to invoke a different version (ex. python -> 2.7, python3 -> 3.4).

A virtualenv is created with a specific version of Python, and hence, it isn't designed to be upgradable. You'll just need to create a new virtualenv with each new Python version and reinstall the requisite packages. If you use a package manager such as pip, or even better, a requirements.txt, this reinstallation shouldn't be much work.

HTH

1
zynixCpt. Code Monkey & Internet of tomorrow•

Reference for others, to make a requirements.txt file pip freeze > requirements.txt will print out almost everything, 99.9% except for bad/broken packages, installed with the versions.

You can then use that file with pip to reinstall everything for a new virtualenv setup.

1
caleb•
$ wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh ~/miniconda.sh
$ ~/miniconda.sh -b -p $HOME/miniconda
$ conda create -n py35env python=3.5
$ conda create -n py34env python=3.4
$ conda create -n py27env python=2.7
$ source activate py35env

This was typed from memory, you may have to fix some things.

1
TheBlackCat13•

Switch to a rolling release distro.

1