By default when I type python in terminal it goes to python using the 2.7.x version. In oldest versions of macOS once I typed 'alias pyhton=python3' it changed forever and every time I typed python it goes to python version 3.
But in macOS Catalina, I need to type the statement every time I open the terminal.
Any suggestion?
First up, confirm what your default "python" links to, so you can reference it, and ensure that which and the shell agree:
user:~> which python
/usr/bin/python
user:~> type python
python is /usr/bin/python
user:~> ls -la /usr/bin/python
lrwxrwxrwx 1 root root 7 Oct 8 13:26 /usr/bin/python -> python2
Now you can either add an alias to override this in your shell... .
Open your ~/.bash_profile file for bash or ~/.zshrc file for zsh (look here for historical reasons behind the files used) as suggested by shahaf, and add a line with the alias — for example, quick method:
echo "alias python=/usr/bin/python3" >> ~/.bash_profile
echo "alias python=/usr/bin/python3" >> ~/.zshrc
The new alias will be set for the next shell you start, or, open a new Terminal window and source the profile file to make it active. Eg. in bash:
source ~/.bash_profile
Or, change the symlink to point by default to python3, and remember the change (I use a simple toggle script, else any install of a missing python2 package can result in complaints about the configure script, which uses the python symlink directly):
#!/bin/bash
TOGGLE=$HOME/.python3Active
if [ ! -e $TOGGLE ]; then
touch $TOGGLE
sudo ln -fs python3 /usr/bin/python
ls -la /usr/bin/python
echo "Press any key to continue..."
read
else
rm $TOGGLE
sudo ln -fs python2 /usr/bin/python
ls -la /usr/bin/python
echo "Press any key to continue..."
read
fi
Catalina now uses zsh as the default rather than Bash.
To verify which shell you are using type echo $0 in the terminal
Add alias python='python3' to $HOME/.zshrc
you will have to edit the terminal's profile file, usually reside under ~/.profile
add the alias line there, this files get loaded when a terminal session is started and export environment variables and methods so they will be accessible in that session
I suggest to use a more robust and powerful terminal enhancement like Z-Shell
I'm using ZSH/oh-my-zsh and the regular OSX terminal, though the same problem occurs in iTerm. I'd been using rbenv and nvm without issue, but recently started working with python and pyenv, and have run into the following issue. On loading a new terminal window, I get the following message at the prompt:
Last login: Sat Apr 1 11:56:46 on ttys001
/Users/jackfuller/.zshenv:3: command not found: pyenv
Since installing pyenv, my machine seems noticeably slower. Obviously loading pyenv will slow things down but load times have dropped way off.
The catch is that pyenv works perfectly after the terminal is loaded, and as far as I can tell my .zshrc is configured properly:
alias dev="cd ~/development"
alias gow="cd ~/goworkspace"
alias dl="cd ~/downloads"
export PATH=/usr/local/bin:$HOME/bin:$PATH
export EDITOR='atom -n'
export PAGER='less -f'
export PATH=$HOME/.rbenv/shims:$PATH
RBENV
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi
# NVM
export NVM_DIR="/Users/jackfuller/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
# PYENV
export PYENV_ROOT=/usr/local/opt/pyenv
eval "$(pyenv init - --no-rehash)"
# if which pyenv > /dev/null; then eval "$(pyenv init - --no-rehash)";
fi
# For go.
export GOPATH="$HOME/goworkspace"
export PATH=$PATH:/usr/local/go/bin
export GOROOT="usr/local/go"
If anyone can offer any advice/solutions, it would be much appreciated. Environment variables and shell config files seem more temperamental /confusing than they should be.
/Users/jackfuller/.zshenv:3: command not found: pyenv indicates that your error is in .zshenv at line 3. Maybe you could post your .zshenv. Is there a reason the fi after #PYENV is not commented? Also you could do export PATH=... once and not thrice. Try which pyenv to find the path to pyenv and look if its in your $PATH. For Future uses i'd put my aliases into ~/.zsh_aliases and do a source ~/.zsh_aliases in the .zshrc, otherwise it gets pretty ugly once you have some more aliases. Sorry for the bad structured answer ;)
I'm running Mac OS X v10.9.2. When I log onto my terminal I'm immediately greeted by the following:
Last login: Wed May 14 22:45:00 on ttys007
-bash: export: `/Users/NabilKaz/Library/Enthought/Canopy_64bit/User/bin/activate': not a valid identifier
I use Enthought Canopy and I'm guessing it's activating a Python virtual environment?
Here are the contents of my .bash_profile:
export PATH="/usr/local/mysql/bin:$PATH"L_ENV_DISABLE_PROMPT=1 source /Users/NabilKaz/Library/Enthought/Canopy_64bit/User/bin/activate
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
# Added by Canopy installer on 2014-02-19
# VIRTUAL_ENV_DISABLE_PROMPT can be set to '' to make bashprompt show that Canopy is active, otherwise 1
VIRTUAL_ENV_DISABLE_PROMPT=1 source /Users/NabilKaz/Library/Enthought/Canopy_64bit/User/bin/activate
This line:
export PATH="/usr/local/mysql/bin:$PATH"L_ENV_DISABLE_PROMPT=1 source /Users/NabilKaz/Library/Enthought/Canopy_64bit/User/bin/activate
Should be
export PATH="/usr/local/mysql/bin:$PATH"
L_ENV_DISABLE_PROMPT=1 source /Users/NabilKaz/Library/Enthought/Canopy_64bit/User/bin/activate
I have been searching and tried various alternatives without success and spent several days on it now - driving me mad.
Running on Red Hat Linux with Python 2.5.2
Began using most recent Virtualenv but could not activate it, I found somewhere suggesting needed earlier version so I have used Virtualenv 1.6.4 as that should work with Python 2.6.
It seems to install the virtual environment ok
[necrailk#server6 ~]$ python virtualenv-1.6.4/virtualenv.py virtual
New python executable in virtual/bin/python
Installing setuptools............done.
Installing pip...............done.
Environment looks ok
[necrailk#server6 ~]$ cd virtual
[necrailk#server6 ~/virtual]$ dir
bin include lib
Trying to activate
[necrailk#server6 ~/virtual]$ . bin/activate
/bin/.: Permission denied.
Checked chmod
[necrailk#server6 ~/virtual]$ cd bin
[necrailk#server6 bin]$ ls -l
total 3160
-rw-r--r-- 1 necrailk biz12 2130 Jan 30 11:38 activate
-rw-r--r-- 1 necrailk biz12 1050 Jan 30 11:38 activate.csh
-rw-r--r-- 1 necrailk biz12 2869 Jan 30 11:38 activate.fish
-rw-r--r-
Problem, so I changed it
[necrailk#server6 bin]$ ls -l
total 3160
-rwxr--r-- 1 necrailk biz12 2130 Jan 30 11:38 activate
-rw-r--r-- 1 necrailk biz12 1050 Jan 30 11:38 activate.csh
-rw-r--r-- 1 necrailk biz12 2869 Jan 30 11:38 activate.fish
-rw-r--r-- 1 necrailk biz12 1005 Jan 30 11:38 activate_this.py
-rwxr-xr-x 1 necrailk biz
Try activate again
[necrailk#server6 ~/virtual]$ . bin/activate
/bin/.: Permission denied.
Still no joy...
Here is my workflow after creating a folder and cd'ing into it:
$ virtualenv venv --distribute
New python executable in venv/bin/python
Installing distribute.........done.
Installing pip................done.
$ source venv/bin/activate
(venv)$ python
You forgot to do source bin/activate where source is a executable name.
Struck me first few times as well, easy to think that manual is telling "execute this from root of the environment folder".
No need to make activate executable via chmod.
You can do
source ./python_env/bin/activate
or just go to the directory
cd /python_env/bin/
and then
source ./activate
Good Luck.
Go to the project directory. In my case microblog is the flask project directory and under microblog directory there should be app and venv folders. then run the below command, This is one worked for me in Ubuntu.
source venv/bin/activate
Cd to the environment path, go to the bin folder.
At this point when you use ls command, you should see the "activate" file.
now type
source activate
$ mkdir <YOURPROJECT>
Create a new project
$ cd <YOURPROJECT>
Change directory to that project
$ virtualenv <NEWVIRTUALENV>
Creating new virtualenv
$ source <NEWVIRTUALENV>/bin/activate
Activating that new virtualenv
run this code it will get activated if you on a windows machine
source venv/Scripts/activate
run this code it will get activated if you on a linux/mac machine
. venv/bin/activate
The problem there is the /bin/. command. That's really weird, since . should always be a link to the directory it's in. (Honestly, unless . is a strange alias or function, I don't even see how it's possible.) It's also a little unusual that your shell doesn't have a . builtin for source.
One quick fix would be to just run the virtualenv in a different shell. (An obvious second advantage being that instead of having to deactivate you can just exit.)
/bin/bash --rcfile bin/activate
If your shell supports it, you may also have the nonstandard source command, which should do the same thing as ., but may not exist. (All said, you should try to figure out why your environment is strange or it will cause you pain again in the future.)
By the way, you didn't need to chmod +x those files. Files only need to be executable if you want to execute them directly. In this case you're trying to launch them from ., so they don't need it.
instead of ./activate
use source activate
For Windows You can perform as:
TO create the virtual env as: virtualenv envName –python=python.exe (if not create environment variable)
To activate the virtual env : > \path\to\envName\Scripts\activate
To deactivate the virtual env : > \path\to\env\Scripts\deactivate
It fine works on the new python version .
Windows 10
In Windows these directories are created :
To activate Virtual Environment in Windows 10.
down\scripts\activate
\scripts directory contain activate file.
Linux Ubuntu
In Ubuntu these directories are created :
To activate Virtual Environment in Linux Ubuntu.
source ./bin/activate
/bin directory contain activate file.
Virtual Environment copied from Windows to Linux Ubuntu vice versa
If Virtual environment folder copied from Windows to Linux Ubuntu then according to directories:
source ./down/Scripts/activate
I would recommend virtualenvwrapper as well. It works wonders for me and how I always have problems with activating. http://virtualenvwrapper.readthedocs.org/en/latest/
Create your own Python virtual environment called <Your Env _name >:.
I have given it VE.
git clone https://github.com/pypa/virtualenv.git
python virtualenv.py VE
To activate your new virtual environment, run (notice it's not ./ here):
. VE/bin/activate
Sample output (note prompt changed):
(VE)c34299#a200dblr$
Once your virtual environment is set, you can remove the Virtualenv repo.
On Mac, change shell to BASH (keep note that virtual env works only in bash shell )
[user#host tools]$. venv/bin/activate
.: Command not found.
[user#host tools]$source venv/bin/activate
Badly placed ()'s.
[user#host tools]$bash
bash-3.2$ source venv/bin/activate
(venv) bash-3.2$
Bingo , it worked. See prompt changed.
On Ubuntu:
user#local_host:~/tools$ source toolsenv/bin/activate
(toolsenv) user#local_host~/tools$
Note : prompt changed
I had trouble getting running source /bin/activate then I realized I was using tcsh as my terminal shell instead of bash. once I switched I was able to activate venv.
Probably a little late to post my answer here but still I'll post, it might benefit someone though,
I had faced the same problem,
The main reason being that I created the virtualenv as a "root" user
But later was trying to activate it using another user.
chmod won't work as you're not the owner of the file, hence the alternative is to use chown (to change the ownership)
For e.g. :
If you have your virtualenv created at /home/abc/ENV
Then CD to /home/abc
and run the command : chown -Rv [user-to-whom-you want-change-ownership] [folder/filename whose ownership needs to be changed]
In this example the commands would be : chown -Rv abc ENV
After the ownership is successfully changed you can simply run source /ENV/bin/./activate and your should be able to activate the virtualenv correctly.
1- open powershell and navigate to your application folder
2- enter your virtualenv folder ex : cd .\venv\Scripts\
3- active virtualenv by type .\activate
I'm a bit confused with what is happening to run my django apps. When I use the command python manage.py runserver I don't get the appropriate response from the server. However, when I use python2.6 manage.py runserver the server actually runs.
Can someone help me with this confusion and also suggest to me how I can simplify this problem? Ideally I don't want different versions of python and only want to be able to type python manage.py runserver
Yes. It is fairly common. You can find out the location of an executable with which, and resolve symlinks with ls.
$ ls -l `which python`
lrwxrwxrwx 1 root root 9 Jul 13 18:50 /usr/bin/python -> python2.6
$ ls -l `which python3`
lrwxrwxrwx 1 root root 9 Jul 27 22:24 /usr/bin/python3 -> python3.1
On Debian and some other systems, you may need to resolve multiple symlinks.
$ ls -l `which nc`
lrwxrwxrwx 1 root root 20 Oct 7 15:16 /bin/nc -> /etc/alternatives/nc
$ ls -l /etc/alternatives/nc
lrwxrwxrwx 1 root root 15 Oct 7 15:16 /etc/alternatives/nc -> /bin/nc.openbsd
If you want to only type python and get the version you want, make an alias. Add a line to your .bashrc file (or wherever you keep such lines):
alias python=python2.6
Note that this will not affect scripts: if you run "python" in a script, it will get the old version, not an alias. Aliases are only for interactive use.
Yes, it is possible to have two versions of python. The easiest way I've found to make python execute python2.6 (without breaking the other version for anyone else) is by using an alias. To do this, simply edit the following and add it to your ~/.profile file:
alias python=/path/to/your/python2.6
Log out and back in, and when you run python it should execute the correct binary. If you wish to revert back, simply delete this line from your ~/.profile.
Yes, you can have multiple versions of Python sitting side-by-side on your computer.
It sounds like python on your host is symbolically linked to a version other than python2.6. You can find out this version by running:
python --version
...or...
python -V
...if that does not work.
Setting the default Python version depends on how you installed Python in the first place.
For Mac OS X, see How can I change the default Python version on Snow Leopard?