this might be a very simple question but I need your help. I work in a network and I cannot install the programs I want. Anyway, I need to use another version of python, which is installed in the directory /new_version/.
Now, when I type "python" in a shell (I use bash) the command point to the version of python installed in the machine I'm working with. I'd love that when I type "python" this command point to the /new_version/ which I've installed. It would be also better if I can call this "new version" with another command, i.e. python2.
I tried changing the PYTHONPATH in the .bashrc but it didn't work.
alias newpython="/path/to/your/new_version/python"
Add this to your .bashrc, you can then start the new python with newpython and the standard one with python.
Add the line
export PATH=/new_version/:$PATH
to your ~/.bashrc (or ~/.bash_profile) file. Then, whenever you run python, it will find the new version first in your PATH. Note this is PATH, not PYTHONPATH. See the comment by #Aaron.
Edit: Only do it this way if you want python to point to the new version. Use an alias as #cularis suggested if you want to call it something different, or make a symlink with:
ln -s /new_version/python /path/to/a/dir/you/add/to/your/path/newpython
Install virtualenv. With this you can easily set up different Python versions like that:
virtualenv -p /new_version/bin/python
Also, virtualenv enables you to easily install other Python packages via pip install.
And finally, there's a package called tox which can automate testing with different Python versions...
Related
I have been having trouble using the requests package in Python 3.6.5. If I run Python 3.5, it works, but not if I run 3.6.5.
I have been trying to remedy this problem by using a virtual environment, but have not had any luck. I have created the virtualenv using this:
mkvirtualenvwrapper -p /usr/local/bin/python3.5 env_test
When I activate that environment and type python -V, it tells me it is using 3.6.5 still. When I type python3.5 -V though, it tells me it is using Python 3.5.5, and which python3.5 says it is sourced in my virtual environment folder.
I guess that virtualenv is installing other versions of Python into the environment as well, and using 3.6.5 as the default, which I don't understand why, but I need it to access python3.5 when I type python. What can I do here?
As you mentioned in your comment, you have an alias set up, where when you type python, it will automatically run python3.6.
To get past this, you have to avoid the alias. You'll have to look up alias in the man of your shell. If it's bash, you could remove the alias by typing unalias python, but chance are, this will only work in the shell you're currently in. Next time you open up a terminal or otherwise have a need to execute your .bashrc and/or .bash_profile, this will likely execute again. You could look for where your alias is set in those files, and remove that line. Or, if the alias gets set in a file outside your control, you could just add unalias ptyhon into your .bashrc.
Or, if you want to just temporarily avoid it,enclose your command in ' or ". 'python' will avoid the alias.
Once the alias is out of your way, what python will likely point you to an area in your virtual env, which should then be a symbolic link to the right version of python.
I am using ZSH. I was having trouble running the Anaconda package manager commands in my terminal. I found that I could add the bin to my PATH using this code:
export PATH="$HOME/anaconda3/bin:$PATH"
That worked. All of the Anaconda and associated commands work and it left me with this PATH:
/Users/USER/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
But the PATH variable would reset each time I closed the terminal window. After some research, I figured out how modify my .zshrc to make it permanent. I simply pasted this into my .zshrc:
export PATH=/Users/USER/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.6/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin
All the commands work and are permanent, but aren't I setting myself up for failure down the road? Everything in the PATH, minus the "/Users/USER/anaconda3/bin" were set automatically. What happens when I update Python, for example? How can I include the "USER/anaconda3/bin" portion of my PATH in my .zshrc without being so explicit?
Your PATH concern is not zsh specific. You could organize things differently.
For example, you could decide to add a directory $HOME/bin/ early in your PATH and put inside that $HOME/bin/ symbolic links to the executables (or scripts) that you want to use. BTW, I recommend to have a short PATH (containing some $HOME/bin/ etc...) since it is more efficient and less messy to understand.
What happens when I update Python, for example?
Let's suppose that Python is installed in your system in /usr/bin/python (and that you use some Linux distribution -or some other Unix- with a good package manager dealing with that;on MacOSX consider homebrew). When that file /usr/bin/python is updated, any future exec of it (e.g. by some shell) will use the new version. Read carefully execve(2).
If ou have several Python-s and the one you want to use is under /Library/Frameworks/Python.framework/Versions/3.6/bin and you upgraded it to some Python 3.7 installed under /Library/Frameworks/Python.framework/Versions/3.7/bin you would need to change your PATH.
If you followed my suggestion, you would (for example) just have a symlink from $HOME/bin/python to /Library/Frameworks/Python.framework/Versions/3.6/bin/python and you would upgrade that symlink when installing Python3.7 using for example:
# remove the old symlink
rm -v $HOME/bin/python
# add the new one
ln -sv /Library/Frameworks/Python.framework/Versions/3.7/bin/python \
$HOME/bin/python
In all cases, you are responsible of having a good enough PATH (and preferably a short one).
At some point when I first started programming and had no idea what I was doing, I installed python 2 in some idiotic way. My python env currently points to python2.7, but for the life of me I cannot find where this is set. I checked my .bash_profile, .bashrc, and the similar files. Also when I type env it is not listed as one of the env variables. How can I determine where my python env variable is set? I'd like it to point to python3 not python2
There's probably a symlink in /usr/bin that's getting resolved to python2
I'd like it to point to python3 not python2
Then edit one of those bashrc or profile files yourself such that Python3 is on the PATH before everything else
Personally, I use pyenv rather than trusting the OS package installers
Assuming you have Python 2 and 3 installed, a simple and safe workaround is to just specify the version explicitly like this:
python2 yourProgram.py
python3 yourProgram.py
Assuming you're using Linux, you could even create an alias:
alias python=python3
That way you can just type
python yourProgram.py
Changing the symlink in /usr/bin is not recommended because there might be system programs using Python 2 which could then potentially break.
In my home, I have a directory named lib/python2.7 (there are actually five directories like that, for different python versions). Since this is a shared hosting (Webfaction), that directory is fundamental to me. There, I have stuff like virtualenv and virtualenvwrapper installed, since as customer of a shared hosting, I have no access to sudo and installing global packages.
However, when I create a virtualenv:
$ mkvirtualenv myenvironment
$ workon myenvironment
$ which pip
# outputs the myenvironment's path to pip
$ pip freeze
The command shows the whole packages list under my lib/python2.7 (this includes the same virtualenv packages, and conflicting packages I have due to... legacy... reasons). This also annoys me if I want to install a package which is the name of a package in lib/python2.7 since it does not allow me to update it.
Right inside the workon environment, I try to check whether the PYTHONPATH has weird stuff, but it is empty:
$ echo $PYTHONPATH
# shows a blank line
It is also empty if I try that command out of any virtual environment.
It seems that --no-site-packages is default but solves just part of the problem. This means: pip freeze | wc -l displays a lesser value when in an environment than when executing globally, out of any environment, which tells me that there are certain already-provided packages that are being excluded and are from the hosting itself (and not installed by me since, again, the hosting is shared and I don't have access to global space).
My question is: How can I solve this? I want my virtualenv not list the packages in $HOME/lib/python2.7
Please avoid dupe-linking to this question, nothing was useful there and still does not have an accepted answer. I wrote this question after reading and trying each solution in that question
I think you need to specify python version. You can specify python version with which you want to create virtual environment using command like
virtualenv -p /usr/bin/python3.4 virt/virtname --no-site-packages
Because when you not specify a python version, virtualenv creates a environment with pythonv2.7 and hence all packages end up in the folder you mentioned.
Found the solution after deeply digging. This is a Webfaction custom but this could apply to any installation like this if the problem occurs.
The core of the problem is that Webfaction configured a sitecustomize.py file for us. The file is located at /usr/local/lib/pythonX.Y/sitecustomize.py and adds by itself the contents of ~/lib/pythonX.Y (and conditionally the contents of any python app under ~/webapps if you are working under a directory of it to run a python script).
Even when the virtualenv's python executable is a different one, it will load the said sitecustomize.py file each time it runs as the base python executable does.
The workaround here? Create an empty sitecustomize.py in your virtualenv to override the other:
touch ~/.virtualenvs/yourvenv/lib/pythonX.Y/sitecustomize.py
And it will work. Take this as reference if you are stuck here like I was
Notes: Replace X.Y on each case with the corresponding version you are working. Additionally remember: You cannot remove or edit the base sitecustomize.py since you are in a shared hosting, in this case. However, overriding will work for each case as long as you do this for every virtualenv you want.
I want to install python using homebrew and I noticed there are 2 different formulas for it, one for python 2.x and another for 3.x. The first symlinks "python" and the other uses "python3". so I ran brew install python3.
I really only care about using python 3 so I would like the default command to be "python" instead of having to type "python3" every time. Is there a way to do this? I tried brew switch python 3.3 but I get a "python is not found in the Cellar" error.
You definitely do not want to do this! You may only care about Python 3, but many people write code that expects python to symlink to Python 2. Changing this can seriously mess your system up.
If you're doing this for personal use, don't change the symlink for python. Many of your system programs depend on python pointing to Python 2.6, and you'll break them if you change the symlink.
Instead, pick a shorter name like py and write an alias for it in ~/.bashrc, like alias py=python3.
For example, with testing:
$ echo "alias py=python3" >> ~/.bashrc
$ bash
$ py
>>> 3+3
6
This will give you the convenience without effecting the system or other users.
If you are absolutely sure that you will never want to install / use Python 2, I think you can just create additional symlinks in /usr/local/bin.
Check for everything that links to something in
../Cellar/python3/3.3.0/
and create a link without the 3 at the end, like
python -> ../Cellar/python3/3.3.0/bin/python3
Think twice though, why give up the advantages of having two Pythons side-by-side? Maybe just use the homebrew Python as intended, and create your Python 3 environments with virtualenv.
Yes, far better to use [virtual environments] (https://docs.python.org/3/library/venv.html) for python 3 than mess with the system default
pyvenv /path/to/new/virtual/environment
which will setup python 3 as the default python and also isolate pip installs to that environment which is what you want to do on any project.
As mentioned this is not the best idea. However, the simplest thing to do when necessary is run python3 in terminal. If you need to run something for python3 then run python3