What's the best way to install two versions of python - python-2.7

I want a easy and clean installation, in case a need to uninstall in future.
I'm running Sierra on my mac, currently I have a Anaconda 2.4 (with python 2.7) and now I need to use python 3.5 too. I looked to quite a few answers and the process seemed a little tricky to un-do if necessary.
Please, if possible, post also the uninstall process. Thanks.

Don't let the long answer intimidate you, the process can be resumed to 6 lines (really), but I tried to write the answer that I was looking for.
The option that suit me the best is virtualenv.
Installation
The simplest way is using brew:
brew install pyenv pyenv-virtualenv pyenv-virtualenvwrapper
to check the list of python versions we can use the command:
pyenv install -l
since I am interested in 3.5.1, I can easily install with the same command
pyenv install 3.5.1
Setup
Once installed, we can check the result using
$ pyenv versions
* system
3.5.1 (set by /Users/macbookpro/.pyenv/version)
this command list all versions installed, and indicates that I'm currently using system's version.
Before we change to 3.5.1 version we need to add pyenv path to .bash_profile.
In the file .bash_profile :
add the following lines. Pay attention if the PATH variable is the same in your case.
#added for pyenv
export PATH="/Users/macbookpro/.pyenv:$PATH"
eval "$(pyenv init -)"
eval "(pyenv virtualenv-init -)"
So now we have everything setup, let's test it
First, we check which version is currently in use:
$ pyenv versions
* system
3.5.1 (set by /Users/macbookpro/.pyenv/version)
Ok, now we know we have to change to 3.5.1. We can do it using:
$ pyenv global 3.5.1
$ python
Python 3.5.1 (default, Oct 20 2016, 21:43:48)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
We also verified that this is actually working. We now test the system version too.
$ pyenv global system
$ pyenv versions
* system (set by /Users/macbookpro/.pyenv/version)
3.5.1
$ python
Python 2.7.12 (default, Sep 5 2016, 20:55:16)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Everything is working fine.
Uninstall
Simply :
$ rm -fr ~/.pyenv
And remove all the .bash_profile stuff that we added in setup.
Extras
For the Anaconda folk.
In jupyter :
In [1]: import sys
sys.version
Out [1]: '2.7.12 |Anaconda 4.1.1 (x86_64)| (default, Jul 2 2016, 17:43:17) \n[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)]'
Nothing changed.

The best way is to use virtualenv. It allows you to keep different working versions of python on the same machine without interfering with each other.
EDIT:
These are the instructions on how to install virtualenv on Mac OS.
Install the latest python version on your system:
brew install python (or python3)
Then using pip:
pip install virtualenv
Then in your home directory edit the .bashrc file. Create it if it doesn't exist. Add this line to the .bashrc file:
export PIP_REQUIRE_VIRTUALENV=true
The line above will make pip run only in virtual environment.
Apply the changes:
. .bashrc (if you in your home directory, note the dot and space before .bashrc file).
Now you should be able to use virtualenv.
If you in your project folder:
virtualenv some_venv
Then activate it:
. ./some_venv/bin/activate (note the dot).
Then you can install everything you need using pip. All the packages will go to the some_venv directory.
You want to deactivate the virtualenv, then run deactivate.
If you want to delete all the installed packages when you were under virutalenv, then just delete some_venv. That's it.
Regarding the pyenv. Honestly I have never used it. But there is an easy to follow tutorial on the github page of the project.
Hope it helps.

Related

Django & GDAL - Could not find the GDAL library

I have a macbook with the M1 Chip and I'm trying to set up a django project. The project works with Geospatial libraries gdal.
I installed gdal with homebrew on version 3.3.1_3 and inside my virtual env version 3.3.1
If I type python manage.py migrate I get an error:
django.core.exceptions.ImproperlyConfigured: Cloud not find the GDAL
library (tried "gdal", "GDAL", "gdal3.1.0", "gdal3.0.0", "gdal2.4.0",
"gdal2.3.0", "gdal2.2.0", "gdal2.1.0"). Is GDAL installed? If it is,
try settings GDAL_LIBRARY_PATH in your settings.
By pip list shows me GDAL at version 3.1.0. The Django Docs say version 3.3.x is not supported but I cant install a specific gdal version with homebrew.
Is there a different solution to get the django project up and running?
I happen to own new MacBook M1 Pro and facing some issue. Here are the steps I did that helped me resolved this issue.
Step 1: First check whether you have installed gdal and geos.
gdal-config --version
If no version shows up, then run brew install gdal in your terminal.
Step 2: Find out path of your gdal installation.
which gdal-config
This should return in case of M1 Mac OS -
/opt/homebrew/opt/gdal/bin
Step 3: Check if gdal lib file is present in below location.
/opt/homebrew/opt/gdal/lib/libgdal.dylib
If it does, then great! Do the same setps for geos if you require that as well.
Once all done, in your Django Project in Settings.py,
Add below lines.
GDAL_LIBRARY_PATH = '/opt/homebrew/opt/gdal/lib/libgdal.dylib'
GEOS_LIBRARY_PATH = '/opt/homebrew/opt/geos/lib/libgeos_c.dylib'
It should work now. Also if you have installed and using PostgreSQL it does come with GDAL and GEOS libs, you can also give those paths as well if needed.
Unfortunately the suggestions by #Ameya didn't work for me, but they did send me down the right path in my investigation. The root cause of my issue was related to python ctypes, from the pyenv distro that I use, not being able to find the GDAL shared library installed from homebrew. Below are some other explanations that I found during my investigation.
The following thread on python bugs gives some good background and detail into Apple's semi-recent(?) increased security constraints that were causing the underlying issue:
https://bugs.python.org/issue43964
This post on pyenv's github gives excellent detail on the issue and why pyenv does not have a general purpose solution:
https://github.com/pyenv/pyenv/issues/2339
Here is one way to test if you are having the same underlying issue that I did. Start a python shell and try to manually load the library with ctypes:
╰─➤ python3
Python 3.10.8 (main, Dec 5 2022, 14:59:49) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
--> from ctypes.util import find_library
--> find_library('libgdal.dylib')
If ctypes finds the library, a path is shown. If no lib is found, no response is given.
It appears that the ctypes loader now(?) only has a fixed set of paths on macos. The work-around that I used is to simply find one of the existing paths that was not used. I then created a symbolic link there, pointing to the homebrew libs location. For example ctypes appears to search $HOME/lib and /usr/local/lib, both of which were empty (or non-existent) on my machine. So I created a symbolic link as follows:
╰─➤ sudo ln -s /opt/homebrew/lib /usr/local/lib
or
╰─➤ ln -s /opt/homebrew/lib ~/lib
Now ctypes finds the library and as a result, django starts properly:
╰─➤ python3
Python 3.10.8 (main, Dec 5 2022, 14:59:49) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
--> from ctypes.util import find_library
--> find_library('libgdal.dylib')
'/usr/local/lib/libgdal.dylib'
-->

How to make iPython use Python 2 instead of Python 3

I have both Python 2.7 and 3.5 installed. If I run a script from the command line using python, it uses Python 2.7, but if I launch iPython, it uses Python 3:
kurt#kurt-ThinkPad:~$ python -V
Python 2.7.12
kurt#kurt-ThinkPad:~$ ipython
Python 3.5.2 (default, Sep 10 2016, 08:21:44)
Type "copyright", "credits" or "license" for more information.
IPython 5.1.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]:
Is there a way to launch iPython so that it uses Python 2? (I'm using Ubuntu LTS 16.04).
Less intrusive solution(as my solution below does not need changing any library files) to this problem is
python2.7 -m IPython notebook
so the general command is
{{python-you-want-ipython-to-use}} -m IPython notebook
Why will this work ?
Because if you see the ipython script (/usr/local/bin/ipython) it seems to be a python script by itself and it has the shebang (#!/usr/bin/python3), so the ipython is not a standalone binary, but it gets life because of some python. So as that ipython script itself needs some python to run it, so you run the ipython module directly using some python of your choice instead of letting that /usr/local/bin/ipython to decide it for you, and that is the fix for the problem of ‘what python ipython uses’.
Following ipython reads wrong python version, in /usr/local/bin/ipython, I simply changed
#!/usr/bin/python3
in the first line to
#!/usr/bin/python
and Python 2 has become the default version used by iPython:
kurt#kurt-ThinkPad:~$ ipython
Python 2.7.12 (default, Jul 1 2016, 15:12:24)
Type "copyright", "credits" or "license" for more information.
IPython 2.4.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
now IPython 6.0+ does not support Python 2.6, 2.7, 3.0, 3.1, or 3.2.
When using Python 2.7, please install IPython 5.x LTS Long Term Support version.
Beginning with IPython 6.0, Python 3.3 and above is required.
I select what python version execute by means of py, like this:
py -2.7 -m IPython
where 2.7 is the version I need.
Following cel's second solution (for non-Anaconda users) on Using both Python 2.x and Python 3.x in IPython Notebook, I set up two virtual environments for Python 2 and Python 3, and installed iPython separately on each.

Is it possible to use python 2.7 with julia while anaconda is preinstalled with python 3.4?

I installed julia and am using some nice python packages like matplotlib in julia using PyCall. I have installed all python stuff with anaconda and used python 3.4. I am able to switch from enviroment in anaconda to use python 2.7.
The thing is that I would like to import openCV as a python package in julia but it only runs with python 2.7. So I was wondering if it was possible to use python 2.7 in julia trough anaconda while python 3.4 was in anaconda's main install.
A working option would be to reinstall anaconda with version 2.7, but I don't want that.
Thanks in advance,
Frank
Current Anaconda installation
OpenCV3 on Python3
The thing is that I would like to import openCV as a python package in julia but it only runs with python 2.7.
Have you tried installing OpenCV3 with your Anaconda Python version 3.x installation?
conda install -c https://conda.anaconda.org/menpo opencv3
Add another Python 2.7 environment
You could also create new Anaconda Python environment with Python 2.7 installed using your current Anaconda install with conda create:
conda create -n py27 python=2.7 anaconda
Assuming you are using the full Anaconda distribution, I understand this will install a full Anaconda Python 2.7 environment (see miniconda, below), but it will not mess up your previous Anaconda Python 3 env.
http://conda.pydata.org/docs/py2or3.html#install-a-different-version-of-python
Conda.jl Julia package
You could use Conda.jl for managing Julia binary dependencies:
This package allows one to use conda as a binary provider for Julia. While other binary providers like Hombrew.jl, AptGet.jl or WinRPM.jl are platform-specific, Conda.jl is a cross-platform alternative. It can also be used without administrator rights, in contrast to the current Linux-based providers.
conda is a package manager which started as the binary package manager for the Anaconda Python distribution, but it also provides arbitrary packages. Instead of the full Anaconda distribution, Conda.jl uses the miniconda Python environment, which only includes conda and its dependencies.
You can install it by running Pkg.add("Conda") at the Julia prompt.
Install and load Conda.jl:
julia> # Pkg.add("Conda")
julia> using Conda
Search for the package:
julia> Conda.search("opencv")
1-element Array{AbstractString,1}:
"opencv"
Install the package:
julia> Conda.add("opencv")
Fetching package metadata: ....
Solving package specifications: ....................
Package plan for installation in environment /home/ismaelvc/.julia/v0.4/Conda/deps/usr:
The following packages will be downloaded:
package | build
---------------------------|-----------------
jpeg-8d | 0 699 KB
wheel-0.29.0 | py27_0 81 KB
opencv-2.4.10 | np110py27_1 9.2 MB
------------------------------------------------------------
Total: 10.0 MB
The following NEW packages will be INSTALLED:
jpeg: 8d-0
opencv: 2.4.10-np110py27_1
The following packages will be UPDATED:
wheel: 0.26.0-py27_1 --> 0.29.0-py27_0
Fetching packages ...
jpeg-8d-0.tar. 100% |##########| Time: 0:00:01 652.02 kB/s
wheel-0.29.0-p 100% |##########| Time: 0:00:00 336.94 kB/s
opencv-2.4.10- 100% |##########| Time: 0:00:10 962.48 kB/s
Extracting packages ...
[ COMPLETE ]|##########| 100%
Unlinking packages ...
[ COMPLETE ]|##########| 100%
Linking packages ...
[ COMPLETE ]|##########| 100%
Total: 10.0 MB
Check that it worked:
shell> .julia/v0.4/Conda/deps/usr/bin/python
Python 2.7.11 |Continuum Analytics, Inc.| (default, Dec 6 2015, 18:08:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
Anaconda is brought to you by Continuum Analytics.
Please check out: http://continuum.io/thanks and https://anaconda.org
>>> import cv2
>>> cv2.__version__
'2.4.10'
>>>
Within Julia via PyCall:
julia> using PyCall # Pkg.add("PyCall")
julia> #pyimport cv2
julia> #pyimport sys
julia> sys.version |> println
2.7.11 |Continuum Analytics, Inc.| (default, Dec 6 2015, 18:08:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
julia> import Conda
julia> Conda.PYTHONDIR
"/home/ismaelvc/.julia/v0.4/Conda/deps/usr/bin"
Specify the python version for PyCall
https://github.com/stevengj/PyCall.jl#specifying-the-python-version
Miniconda
Or use miniconda for Python 2.7 directly:
http://conda.pydata.org/miniconda.html
Conda.jl installs by default the Python version 2.7.x miniconda (installing everything in ~/.julia/v0.x/Conda).
In Linux:
It is often very easy to install only the things you want, without having to use Anaconda (I'm assuming you use Mac or PC, but still useful to others), example uses ArchLinux package manager pacman, it's similar with other Linux distributions package managers like: yum, zipper, apt-get, etc:
shell> sudo pacman -S opencv
warning: opencv-2.4.12.2-2 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Package (1) Old Version New Version Net Change Download Size
extra/opencv 2.4.12.2-2 2.4.12.2-2 0.00 MiB 7.10 MiB
Total Download Size: 7.10 MiB
Total Installed Size: 38.86 MiB
Net Upgrade Size: 0.00 MiB
:: Proceed with installation? [Y/n] n
shell> python2
Python 2.7.11 (default, Dec 6 2015, 15:43:46)
[GCC 5.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import cv2
>>> cv2.__version__
'2.4.12.2'
>>>

/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.8' not found

It turns out that "make install" - the make target that installs and implies the target "install-target-libstdc++v3" doesn't actually mean you're ready to go.
I've been stuck for a while wondering what I was doing wrong because I assumed that such a make target would do that for me.
Add the library's path to the LD_LIBRARY_PATH environment variable
TL;DR
GCC requires you to tell it where your library is located manually when it can't find the right version, which can be done in a few ways. One is adding it to the LD_LIBRARY_PATH.
export LD_LIBRARY_PATH="/usr/local/lib64/:$LD_LIBRARY_PATH"
For some, the library path will be /usr/local/lib64/. Others have reported the library path /usr/lib/x86_64-linux-gnu/ working for them instead.
Why do we need to add the library to LD_LIBRARY_PATH?
When you compile and install GCC it puts the libraries in one of these directories, but that's all it does. According to the FAQs for libstdc++, the error that we got means that the dynamic linker found the wrong version of the libstdc++ shared library. Because the linker can't find the right version, we have to tell it where to find the libstdc++ library.
The simplest way to fix this is to use the LD_LIBRARY_PATH environment variable, which is a colon-separated list of directories in which the linker will search for shared libraries.
There are other ways as well to fix this issue. You can find this and the other solutions mentioned briefly when you install gcc if you read the make output:
Libraries have been installed in:
/usr/local/lib/../lib32
If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following:
add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution
add LIBDIR to the `LD_RUN_PATH' environment variable during linking
use the `-Wl,-rpath -Wl,LIBDIR' linker flag
have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages.
Grr, that was simple! Also, "if you ever happen to want to link against the installed libraries," seriously?
I had the same problem on my Ubuntu 14.04 when tried to install TopTracker. I got such errors:
/usr/share/toptracker/bin/TopTracker:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.8' not
found (required by /usr/share/toptracker/bin/TopTracker)
/usr/share/toptracker/bin/TopTracker:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'GLIBCXX_3.4.21' not
found (required by /usr/share/toptracker/bin/TopTracker)
/usr/share/toptracker/bin/TopTracker:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6: version 'CXXABI_1.3.9' not
found (required by /usr/share/toptracker/bin/TopTracker)
But I then installed gcc 4.9 version and problem gone:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
I've got correct solution here.
The best way to correctly install gcc-4.9 and set it as your default gcc version use:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9
The --slave, with g++, will cause g++ to be switched along with gcc, to the same version. But, at this point gcc-4.9 will be your only version configured in update-alternatives, so add 4.8 to update-alternatives, so there actually is an alternative, by using:
sudo apt-get install gcc-4.8 g++-4.8
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.8
Then you can check which one that is set, and change back and forth using:
sudo update-alternatives --config gcc
NOTE: You could skip installing the PPA Repository and just use /usr/bin/gcc-4.9-base but I prefer using the fresh updated toolchains.
In my case it was gcc 6 the one missing
sudo apt-get install gcc-6 g++-6 -y
Update
sudo apt-get install gcc-7 g++-7 -y
This solution work on my case i am using ubuntu 16.04, VirtualBox 2.7.2 and genymotion 2.7.2
Same error come in my system i have followed simple step and my problem was solve
1. $ LD_LIBRARY_PATH=/usr/local/lib64/:$LD_LIBRARY_PATH
2. $ export LD_LIBRARY_PATH
3. $ sudo apt-add-repository ppa:ubuntu-toolchain-r/test
4. $ sudo apt-get update
5. $ sudo apt-get install gcc-4.9 g++-4.9
I hope this will work for you
What the other answers suggest will work for the program in question,
but it has the potential to cause breakage in other programs and unknown dependence elsewhere. It's better to make a tiny wrapper script:
#!/bin/sh
export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
program_needing_different_run_time_library_path
This mostly avoids the problem described in Why LD_LIBRARY_PATH is bad by confining the effects to the program which needs them.
Note that despite the names LD_RUN_PATH works at link-time and is non-evil, while LD_LIBRARY_PATH works at both link and run time (and is evil :).
I ran into this issue on my Ubuntu-64 system when attempting to import fst within python as such:
Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun 4 2015, 15:29:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fst
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/ogi/miniconda3/lib/python3.4/site-packages/pyfst-0.2.3.dev0-py3.4-linux-x86_64.egg/fst/__init__.py", line 1, in <module>
from fst._fst import EPSILON, EPSILON_ID, SymbolTable,\
ImportError: /home/ogi/miniconda3/lib/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /usr/local/lib/libfst.so.1)
I then ran:
ogi#ubuntu:~/miniconda3/lib$ find ~/ -name "libstdc++.so.6"
/home/ogi/miniconda3/lib/libstdc++.so.6
/home/ogi/miniconda3/pkgs/libgcc-5-5.2.0-2/lib/libstdc++.so.6
/home/ogi/miniconda3/pkgs/libgcc-4.8.5-1/lib/libstdc++.so.6
find: `/home/ogi/.local/share/jupyter/runtime': Permission denied
ogi#ubuntu:~/miniconda3/lib$
mv /home/ogi/miniconda3/lib/libstdc++.so.6 /home/ogi/miniconda3/libstdc++.so.6.old
cp /home/ogi/miniconda3/libgcc-5-5.2.0-2/lib/libstdc++.so.6 /home/ogi/miniconda3/lib/
At which point I was then able to load the library
ogi#ubuntu:~/miniconda3/lib$ python
Python 3.4.3 |Continuum Analytics, Inc.| (default, Jun 4 2015, 15:29:08)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import fst
>>> exit()
Had the same error when installing PhantomJS on Ubuntu 14.04 64bit with gcc-4.8 (CXXABI_1.3.7)
Upgrading to gcc-4.9 (CXXABI_1.3.8) fixed the issue. HOWTO:
https://askubuntu.com/questions/466651/how-do-i-use-the-latest-gcc-4-9-on-ubuntu-14-04

Can't find django-admin.py in Lubuntu 12.10

I just installed Lubuntu 12.10 on a new laptop, and I'm trying to get Django working. I installed it from Synaptic Package Manager, and when I try to make a sample project on the command line, this is what I get:
amanda#amanda-ThinkPad-E420:~$ django-admin.py startproject caltrain
django-admin.py: command not found
And I verified Django is installed correctly,
amanda#amanda-ThinkPad-E420:~$ python
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print(django.get_version())
1.4.1
>>>
Is this some sorta path issue or something? I don't remember having this issue on my Mac, but again I'm not very Unix savvy to begin with.
This information may be a bit stale, but I found this information that seems similar to your problem: http://ubuntuforums.org/showthread.php?t=1267372
With this solution:
Name of "django-admin.py" was changed to "django-admin" in /usr/bin directory in the python-django package.
To get around this I just created a symbolic link to django-admin named django-admin.py.
ln -s /usr/bin/django-admin /usr/bin/django-admin.py (as root)
Hope this helps, but again this was written in 2009.
You should see this. it contains details concerning problems with django-admin.py location
https://docs.djangoproject.com/en/1.6/faq/troubleshooting/#troubleshooting-django-admin-py