We Keep Coding

How install and use another version python(python 2.7) on linux with the default python version is python 2.6

There is a default python version, namely python 2.6, on the GPU server with Linux OS. Now I want to install a new python version on the server from its source, namely python 2.7. I should not change the default python version since I am not the administrator and some reason. So what should I do?

You can install your new version of Python. It should be accessible with the python27 command (which may be a symbolic link).
Then you will just have to check that the python symbolic link still points to python26.
Doing this, python will keep on execute Python 2.6 while python27 will execute Python 2.7

You can use virtualenv, to execute your programm in an environment with python 2.7.
Install virtualenv and virtualenvwrapper (for comfotable use.)
mkvirtualenv -p <your-python-version> would then start a virtual environment where the desired python version is the default.

To build on Tryph's answer, you can install that new version to your home directory, then in a directory specified within your PATH (like in .bash_profile), you can point to that directory and within there create a sym-link that points to the new python.
For instance, if you have a bin folder in your home directory that is specified in the path
ln -s /bin/python ~/bin/python

Error Installing OpenCV with Python on OS X

I have been trying to install Open CV 3 on my mac using this tutorial but I cannot get past step three.
So after I do
brew install python
I do
nano ~/.bash_profile
And the at the bottom of the script I paste
# Homebrew
export PATH=/usr/local/bin:$PATH
After that I reload the file like this
source ~/.bash_profile
Finally I check the python like this
which python
And it prints
/usr/bin/python
instead of
/usr/local/bin/python
I have also tried edited the file in TextEdit but it has the same result.
Am I doing something wrong or is this just a bad tutorial?
Thank You in Advance!
Edit:
# Setting PATH for Python 3.5
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}"
export PATH
##
# Your previous /Users/UserName/.bash_profile file was backed up as /Users/UserName/.bash_profile.macports-saved_2016-07-26_at_12:50:19
##
# MacPorts Installer addition on 2016-07-26_at_12:50:19: adding an appropriate PATH variable for use with MacPorts.
export PATH="/opt/local/bin:/opt/local/sbin:$PATH"
# Finished adapting your PATH environment variable for use with MacPorts.
# Homebrew
export PATH=/usr/local/bin:$PATH
pydoc3.5
python3
python3-32
python3-config
python3.5
python3.5-32
python3.5-config
python3.5m
python3.5m-config

Is there a
/usr/local/Cellar/python/2.7.12/
directory? (Version number might differ.)
Is there a
/usr/local/bin/python
file?
If the Cellar directory is present, but the file isn't, then Homebrew decided to be careful and not put Python in /usr/local/bin/ immediately.
You could manually do
brew link python
and see if there's now a
/usr/local/bin/python
file.
In your case, it appears you have some files related to Python (they might be from a Python 3 installation, can't tell), such as 2to3. You can safely overwrite them, since Python 2 also has this.
Thus:
brew link --overwrite python
is fine.
Note:
Specific Python versions will always exist as python2.7, python3.5 etc (including the full path as necessary). Thus, even overwriting the python executable is safe (provided it's not the system one in /usr/bin): you should then simply be explicit which python executable to use.
Also, when using a tool like pip, you can make sure you're using the correct version by running it e.g. as
/usr/local/bin/pythnon2.7 -m pip <...>
or whatever python executable you want to install things for.

Okay so one brute force solution could be this one https://stackoverflow.com/a/9821036/128517
But maybe you could check the value of your $PATH after source ~/.bash_profile
typing
> echo $PATH
and see if /usr/local/bin is indeed at the beginning.
if it's not, you might need to check if there's another export before yours or maybe you need to edit .profile instead.

What file does the python symlink point to

I bought my mac about a year ago and somehow changed my python symlink so that when I run python some_file.py, python 3.4 is used to run the file instead of python 2.7. I now need to change it back, but I can't figure out what I did to change it in the first place! When I run:
import os
os.path.realpath("/usr/local/bin/python")
in the python terminal, the output is:
'/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7'
Does this not mean that my python symlink is pointing to my python 2.7 version, and not my 3.4 version? If not, how do I find out which file is run when I use the python symlink?

You probably installed that specific Python version using the official Python installer for OS X; see the Using Python on a Macintosh documentation. The installer creates the /usr/local/bin symlink for you.
If you also, at some point, had 3.4 installed then that installation is still there too. Check for a /usr/local/bin/python3 command; it'll link to the existing Python 3 binary. Use that instead to run Python 3 code.
If you do have a /Library/Frameworks/Python.framework/Versions/3.4/bin/python3.4 command, you could re-create the /usr/local/bin/python symlink to point there instead, but I'd personally only use the python3 name for Python 3 scripts.
Last, you could also have used the homebrew tool to install Python; it can manage symlinks for you. However, homebrew installs Python binaries into the /usr/local/Cellar tree structure instead.

Virtual Env on Mac with python 3.4

I am trying to get a django project up and running, and I have django running, but I am having trouble with python's virtualenv.
here is my error (on terminal open this shows up)
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
virtualenvwrapper.sh: There was a problem running the initialization hooks.
If Python could not import the module virtualenvwrapper.hook_loader,
check that virtualenvwrapper has been installed for
VIRTUALENVWRAPPER_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python and that PATH is
set properly.
Here is what My .bash profile looks like:
# Setting PATH for Python 3.4
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/3.4/bin:${PATH}"
export PATH
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
export WORKON_HOME=$HOME/.virtualenvs
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
export PIP_VIRTUALENV_BASE=$WORKON_HOME
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
I am pretty new to command line stuff and virtual environments, so I might not know some "obvious" things I am doing wrong. Thanks.

First some basics of the command-line shell:
PATH is an environment variable that contains a list of filesystem directories. When you type a command such as ls, python or virtualenvwrapper.sh your shell will search each directory starting from the first one listed. To see your current PATH type:
$ echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
To see what a given command is going to resolve to the location of the program that is going to be run, use the which command:
$ which ls
/bin/ls
Now in your example you are first adding a Python 3.4 location to your PATH and then a Python 2.7 location. The latter location is going to be first on your PATH. So all your Python related commands are first going to try and run Python 2.7, if a command isn't found there, it next searches in your Python 3.4 installation.
You appear to have installed virtualenvwrapper for Python 3.4, but when you run virtualenvwrapper.sh from the line:
source /Library/Frameworks/Python.framework/Versions/3.4/bin/virtualenvwrapper.sh
You are explicitly running the virtualenvwrapper.sh installed for Python 3.4. This runs a python command where your Python 2.7 is run, which does not appear to have virtualenvwrapper installed, as shown by this error message:
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named virtualenvwrapper
If you tried removing the Python 2.7 location addition to your PATH and it didn't work, you have to remember that changes to your .bash_profile are not automatically reflected in your terminal. You have to create a new terminal session and that new session will read your new .bash_profile.
If you are trying to get the command virtualenv to resolve to two different Pythons, it's simply not possible. It will always resolve to one specific Python based on the ordering of the locations on your PATH. VirtualEnv does install alternate versions of the command with the version of the Python built into the name. Use the commands virtualenv-3.4 and virtualenv-2.7 to create virtual environments for each different Python.
The key to all of this is remembering that PATH is used to resolve to an absolute path location of a program this is run. Use the echo $PATH and which commands to help you understand how that final path is being resolved.
It may seem tedious, but typing out the full absolute path is always going to side-step the magic of PATH resolution:
$ /Library/Frameworks/Python.framework/Versions/2.7/bin/virtualenv
Try using smaller steps on your way to manipulating the path. Use just virutalenv-3.4 to make a Python 3.4 virtual environment and only bring in virtualenvwrapper as you need it and after your understanding of shell environments is more solid.
Finally, even pro's can get tripped up by playing games manipulating the path. You are ultimately trying to take a bunch of different application locations and flatten them all into one namespace. At some point conflicts can become unresolveable. A Python installation tool such as Buildout has it's own learning curve, but it hard-codes the absolute path to the python of each python script that it installs. Hard-coding absolute paths is the only way to deal with extreme corner cases such as having two builds of Python 3.4 side-by-side where you have two scripts which each need to run on two different builds of the same Python. Hard-coding absolute locations is also desirable in production environments, because then your application is immune to any changes to the bash shell. If you forget about a required ordering of your PATH, or another sysadmin tinkers with the PATH, you won't find your application breaking unexpectedly.

Conflicting Python Installs in OSX Mavericks

I've got myself in a pickle and would like some guidance before my laptop suffers GBH.
I have been using my Macbook for a few years without probs but when I got a new iMac at work I noticed everyone recommended useing homebrew for new Python installs (esp. on Mavericks).
Now my laptop has worked fine with the original Python. But I decided to try and do it the new homebrew way (its now Mavericks btw).
First I clear out Mavericks due to some other conflict then reinstall a fresh. Get nginx, php-fpm, mysql, etc working.
Now Python.
I can use pip to install packages. But when I try
workon myproject
I get:
/usr/bin/python: No module named virtualenvwrapper
/usr/bin/python: No module named virtualenvwrapper
But then it switches to that virtualenv anyway - but not the directory that the project is in!
When I run where python I get several entries:
/usr/local/bin/python
/usr/bin/python
/usr/local/bin/python
I've tried fiddling with my path but keep getting other errors that all seem to indicate my two Python installations are conflicting badly. Is there a simple solution or do I need to wipe out hombrew and start again from the beginning? Or just give up on homebrew and use OSX built in?
To clarify my current $PATH is:
/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/op‌​t/X11/bin:/usr/local/go/bin:/Users/me/Development/Android/sdk/tools:/Users/me/Dev‌​elopment/Android/sdk/platform-tools

My solution was an unusual one but here goes:
In my .zshrc file I had the following layout:
ZSH=$HOME/.oh-my-zsh
ZSH_THEME="steeef"
plugins=(osx virtualenv virtualenvwrapper python github)
source $ZSH/oh-my-zsh.sh
# various aliases
export PATH=/usr/local/bin:/usr/local/sbin:$PATH
The problem was the Oh My ZSH plugin virtualenvwrapper was looking in the default python path location as the custom path had yet to be set later in the .zshrc file.
The solution therefore was to move the PATH declaration before the plugins like so:
ZSH_THEME="steeef"
export PATH=/usr/local/bin:/usr/local/sbin:$PATH
plugins=(osx virtualenv virtualenvwrapper python github)
source $ZSH/oh-my-zsh.sh
# various aliases
Now the ZSH plugins are referencing the correct Python install and therefore the correct Python packages path.

Try putting your preferred version earlier in your PATH variable. So if you want to use /usr/local/bin/python, from the command line you could modify your PATH by export PATH=/usr/local/bin/python:$PATH. See here for more info: http://www.cyberciti.biz/faq/appleosx-bash-unix-change-set-path-environment-variable/