On arch linux, after install virtualenvwrapper system-wide, via sudo pip2 install virtualenvwrapper and adding this in my user's .bash_profile,
export WORKON_HOME=/home/myuser/.virtualenvs
export PROJECT_HOME=/home/myuser/work
source /usr/bin/virtualenvwrapper.sh
An error shows up whenever I launch a new shell window:-
which: no python in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl)
-bash: : command not found
virtualenvwrapper.sh: There was a problem running the initialization hooks. If Python could not import the module virtualenvwrapper.hook_loader, check that virtualenv has been installed for VIRTUALENVWRAPPER_PYTHON= and that PATH is set properly.
This can be traced to line 50 in the virtualenvwrapper.sh script:-
47 # Locate the global Python where virtualenvwrapper is installed.
48 if [ "$VIRTUALENVWRAPPER_PYTHON" = "" ]
49 then
50 VIRTUALENVWRAPPER_PYTHON="$(\which python)"
51 fi
And is a result of the conflict with arch linux's convention of using python2 for python 2.7 installation.
If I modify line 50 to which python2, everything works perfectly and I will not see the error message whenever I launch a new shell.
What is the appropriate way of resolving this problem? Do I write an explicit check that the current OS is arch linux and introduce an if-else condition to use which python2 in virtualenvwrapper.sh and send the patch to the virtualenvwrapper author? Or is there something I can do with my configuration in my arch linux machine?
Virtualenvwrapper has variables VIRTUALENVWRAPPER_PYTHON and VIRTUALENVWRAPPER_VIRTUALENV which point to your python and virtualenv executables. So, in your .bash_profile you can write something like:
export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python2
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/bin/virtualenv2
source /usr/bin/virtualenvwrapper.sh
To answer this arch-specific python quirk (the convention of using python2), I specifically create a soft link like this:-
ln -s /usr/bin/python2 /usr/local/bin/python
Since /usr/local/bin precedes /usr/bin in the bash system PATH environment variable, when I type python, or when the virtualenvwrapper.sh script refers to which python in line 50, we will no longer run into the above mentioned virtualenvwrapper conflict and everything works as expected.
The disadvantage of doing this is that it might mess up the "python 3" (being considered as the default python command) conventions arch linux is designed for. So care has to be taken that I do not use python 3 related libraries or package installations relating to python 3 in my target box.
I found there is no need to edit the /usr/bin/virtualenvwrapper.sh script or create a new symbolic link. I was just missing the virtualenvwrapper module for python2. I installed it like the following:
pip2 install virtualenvwrapper
and keeped the exports so the magic is done.
Related
I am trying to get to grips with Python on my Mac running OS X 10.15.7 Catalina.
My goal is to be able to run a program requiring Python 3.9 and associated libraries, in its own virtual environment, using venv.
My quest has led me over many rocky paths and blind alleys - including via Anaconda and Brew.
I am running zsh - specifically oh-my-zsh ys version. If that's important. Most online forums and tutorials assume bash. I would prefer to do all in zsh to avoid having to edit both zsh and bash profiles.
Current Shell Outputs
$ python -V
Python 2.7.16
$ which python
/usr/bin/python
$ python3 -V
Python 3.8.2
$ which python3.8
python3.8 not found
$ which python3.9
python3.9 not found
$ python3 -m -V
/Library/Developer/CommandLineTools/usr/bin/python3: No module named -V
Pausing there ..
Py 2.7 is the OS X system Python and I don't want to do anything with it.
It is odd that python3 -m returns a reference to the CLI tools. See below. The only location for py3.8 is in the CL tools.
What pythons do I have (output below is edited so as to show only main directories and Files)?
$ locate python
/Applications/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework/Versions/3.7/bin/python3
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
/Library/Developer/CommandLineTools/usr/bin/python3.8
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3-config
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9-config
/Library/Frameworks/Python.framework/Versions/3.9/share/man/man1/python3.1
/Library/Frameworks/Python.framework/Versions/3.9/share/man/man1/python3.9.1
/Library/Frameworks/SAVI.framework/Versions/A/Frameworks/Python.framework/Versions/3.6/lib/python3.6
/usr/bin/python
/usr/bin/python-config
/usr/bin/python2
/usr/bin/python2.7
/usr/bin/python2.7-config
/usr/bin/python3
/usr/bin/pythonw
/usr/bin/pythonw2.7
/usr/lib/libpython.dylib
/usr/lib/libpython2.7.dylib
/usr/lib/python2.7
/usr/local/bin/python3
/usr/local/bin/python3-config
/usr/local/bin/python3.9
/usr/local/bin/python3.9-config
/usr/share/file/magic/python
/usr/share/man/man1/python.1
/usr/share/man/man1/python2.7.1
/usr/share/man/man1/pythonw.1
/usr/share/man/man1/pythonw2.7.1
/usr/share/vim/vim81/autoload/python3complete.vim
/usr/share/vim/vim81/autoload/pythoncomplete.vim
/usr/share/vim/vim81/ftplugin/python.vim
/usr/share/vim/vim81/indent/python.vim
/usr/share/vim/vim81/syntax/python.vim
/usr/share/zsh/5.7.1/functions/_bpython
/usr/share/zsh/5.7.1/functions/_python
/usr/share/zsh/5.7.1/functions/_python_modules
WHAT ABOUT PIP?
$ pip3
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
$ pip3 install --upgrade pip
WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: pip in ./Library/Python/3.8/lib/python/site-packages (20.3.3)
Note two points
Although the wrapper warning comes up, PIP 20.3.3 is latest version which I have upgraded. Probably the reason for the warning is in the next lines, which suggest that PIP3 is being invoked from the CL Tools.
2; The ‘normal site-packages is not writeable’ error is supposed to be cured by specifying the Path. I have tried already to specify the correct path - see below - but this has not cured the problem and is another major reason for asking the question at the end of this post.
$ python -m pip
/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python: No module named pip
$ python3 -m pip
Usage:
/Library/Developer/CommandLineTools/usr/bin/python3 -m pip <command> [options]
$ which pip3
/usr/bin/pip3
$ locate pip3
/Applications/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework/Versions/3.7/bin/pip3
/Applications/LibreOffice.app/Contents/Frameworks/LibreOfficePython.framework/Versions/3.7/bin/pip3.7
/Library/Developer/CommandLineTools/usr/bin/pip3
/Library/Developer/CommandLineTools/usr/bin/pip3.8
/Library/Frameworks/Python.framework/Versions/3.9/bin/pip3
/Library/Frameworks/Python.framework/Versions/3.9/bin/pip3.9
/usr/bin/pip3
/usr/local/bin/pip3
/usr/local/bin/pip3.9
SYSTEM FILES
~/.zprofile contents - edited a few times to remove references to virfualenv and penv, both originally installed with brew and now removed. I have run brew uninstall and brew remove to try to clean everything up but may not have succeeded.
Start
# THIS FILE COMMENTED OUT RH 21DEC20
## Setting PATH for Python 3.9
## The original version is saved in .zprofile.pysave. **Note in this post only - cannot find this file**
PATH="/Library/Frameworks/Python.framework/Versions/3.9/bin:${PATH}"
export PATH **Note in this post only - this does not seem to have worked - see above Python3 -V**
# export WORKON_HOME=~/.virtualenvs
# mkdir -p $WORKON_HOME
# . ~/.pyenv/versions/3.9.0/bin/virtualenvwrapper.sh
# eval "$(pyenv init -)"
# # AND THESE LINES ADDED FOLLOWING STACKOVERFLOW Q 33216679 **Note in this post only - commented out as shell threw errors .’cannot find virtualenvwrapper.sh**
# export WORKON_HOME=$HOME/.Envs
# # export VIRTUALENVWRAPPER_PYTHON=$/usr/bin/python3
# export VIRTUALENVWRAPPER_PYTHON=$/usr/local/bin/python3
#source $HOME/.local/bin/virtualenvwrapper.sh
END
Finally a word about Brew. Many tutorials advised the use of Brew to install Python, pyenv, and libraries etc. I did that and successfully created a test environment, but could not the utilise it. I have then removed as much as possible in order to get back to a ‘clean’ state to work with.
Current brew status is
$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!
Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected dylibs:
/usr/local/lib/libdvdcss.2.dylib
/usr/local/lib/libfuse.0.dylib
/usr/local/lib/libulockmgr.0.dylib
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/ulockmgr.h
Warning: Unbrewed .la files were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .la files:
/usr/local/lib/libulockmgr.la
Warning: Unbrewed static libraries were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected static libraries:
/usr/local/lib/libfuse.a
/usr/local/lib/libulockmgr.a
SUMMARY
My first goal is to set Py3.9.x as default for new projects. I think also this would require/imply that pip and other commands run from v3.9 and not any other version or location. Must admit to being hazy about that.
Then I want to be able to create a virtual environment into which I can put the program I want to run and its associated libraries and packages. Doing this implies using terminal, but I need to know which directory I need to be in to run which commands.
At this point I have also been running into confusion with tutorials on how to create a virtual environment. From what I have read I think I should use venv over pyenv. What is not clear is whether I run the venv command (s) from root, or whether I have to create and cd to a different location, and if so what.
Any help in
1 Changing the default Python to 3.9
2 Creating a venv to use v3.9.
3 What commands to run where.
Will be greatly appreciated. Please keep it simple and don't assume any prior knowledge!
This is what I would do :
# For 1 Changing the default python to 3.9
cd /usr/local/bin
sudo ln -fs /Library/Frameworks/Python.framework/Versions/3.9/bin/python3.9 python3
sudo ln -fs python3 python
# And make sure /usr/local/bin is before (/usr/bin and /Library/Developer/CommandLineTools/usr/bin) in your $PATH
# For 2 Creating a venv to use v3.9
/usr/local/bin/python3.9 -m venv /tmp/python3.9-venv
I installed python 3.6 before and installed python 3.7.4 today. When I type python3 in command, it opens python 3.6, I want to change it to python 3.7.4.
which python3 shows /Library/Frameworks/Python.framework/Versions/3.6/bin/python3,
but the link in /usr/local/bin/ is :
python3 -> ../../../Library/Frameworks/Python.framework/Versions/3.7/bin/python3
so is the case of pip3. why? ?
How can I change which python3 to python 3.7.4? I don't want to use alias.
I use MacOS 10.14.2
Your OS uses the PATH environment variable to look for the commands you write into the shell, so if you type python3 it will go through the directories listed in this PATH and check if there's your programm. It takes the first matching program and executes it, so in your case the directory /Library/Frameworks/.../3.6/bin is before the directory usr/local/bin, which means that the python3 from /Library/Frameworks/.../3.6/bin will be used.
You need therefore to change this PATH variable:
export PATH="/Users/sky/Documents/software/Montage-master/bin:/usr/share/file/magic/mercurial:/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/mysql/bin:/Library/Frameworks/Python.framework/Versions/3.6/bin"
You can put that into your ~/.bash_profile so that it is permanent, and you don't need to set it every time you open a new terminal window.
Note that this will not automatically update your path for the remainder of the session. To do this, you should run:
source ~/.bash_profile
Are you sure have python3.7 intalled?
you can view the folder
cd /usr/bin
Next you search the python's file:
find /usr/bin/ python3
if don´t exist filename python3.7 install
sudo apt install python3.7
sudo apt update
I am using Git Bash on windows with python 2.7 and I want to work in a virtual environment.
When I type
virtualenv venv
Bash says
bash: virtualenv: command not found
That makes me think virtualenv is not installed, then I try to install virtualenv
pip install virtualenv
But again Bash says
bash: pip: command not found
Then by reading this thread python 2.7: cannot pip on windows "bash: pip: command not found" I find out that it cannot find the pip directory, that maybe is the same reason for which it cannot find virtualenv directory.
So I specify the path of pip and I try again to instal virtualenv
python -m pip install virtualenv
It installs virtualenv but then tells
DEPRECATION: Python 2.7 will reach the end of its life on January 1st,
2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python
2.7.
So I go forward and try to activate my virtualenv by typing
virtualenv venv
and as I expected I get the same error of before
bash: virtualenv: command not found
that I try to solve in the same way I did for pip, by typing
python -m virtualenv venv
and this time bash responds with
$ python -m virtualenv venv New python executable in
C:\Users\Tommaso\DJANGO~1\UDEMYD~1\METAGL~2\venv\Scripts\python.exe
Installing setuptools, pip, wheel... done.
So I guess it created my virtualenv named venv, but in my bash terminal I still get the writing "(master)" at the end of the input line, that I guess it means the virtual environment is not active.
How do I activate it?
Solved!
Here is what I did.
First, by following this SO answer, I found out how to make Git Bash use python 3.7 instead of python 2.7 by default:
I opened the file aliases.sh with Notepad++, located at
C:<path where you installed Git Bash>\etc\profile.d\aliases.sh
Under the paragraph
--show-control-chars: help showing Korean or accented characters
I added these lines indicating where the two versions of python I want to switch are located
alias python2='C:/<installation_path_of_python_2.7>/Python 2.7/python.exe'
alias python='C:/<installation_path_of_python_3.7>/Python 3.7/python.exe'
alias pip='C:/<installation_path_of_python_3.7>/Phyton/Scripts/pip.exe'
alias virtualenv='C:/<installation_path_of_python_3.7>/Phyton/Scripts/virtualenv.exe'
You don't really need the last 2 ones, but it will help you a lot, since it enables Git Bash to call pip, virtualenv and other scripts without writing python -m before the name of the script.
You can check out if you did right by typing
python -i
It should return you the latest python version you specified.
Then if I type
python -m virtualenv venv
It installs the virtual environment in the current directory
To activate that, just type
. venv/scripts/activate
If it works, you should see
(venv)
near to your active input line.
To deactivate it just type
deactivate
I had the same problem before. The solution is to install virtualenv first using pip. Then:
enter virtualenv nameOfTheEnvironment
nameOfTheEnvironment\Scripts\activate
You should see something like:
C:\Users\bamidele\Documents\DjangoProjects>virtualenv venv
created virtual environment CPython3.7.2.final.0-64 in 15334ms
creator CPython3Windows(dest=C:\Users\bamidele\Documents\DjangoProjects\venv, clear=False, global=False)seeder FromAppData(download=False, pip=latest, setuptools=latest, wheel=latest, via=copy, app_data_dir=C:\Users\bamidele\AppData\Local\pypa\virtualenv\seed-app-data\v1.0.1)activators BashActivator,BatchActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
C:\Users\bamidele\Documents\DjangoProjects>venv\Scripts\activate
(venv) C:\Users\bamidele\Documents\DjangoProjects>```
I hope this solves your problem.
In git bash, cd into the virtual environment(venv) directory of your project and use this command
source ./Scripts/activate
to activate virtual environment(venv)
You can go
cd venv\Scripts
path. Then:
Run the command
activate
This run on my Flask project.
I would like to make the version of python 2 packaged with MacOS the system default Please show me the recommended approach.
I have installed a Python 3 version from miniconda/anaconda, and my current default Python is:
$ which python
/Users/PatrickT/miniconda3/bin/python
I do not want this to be the default Python anymore. The dilemma is: if I remove conda from the PATH, I can access the Python version packaged with the OS, but then I can no longer access the conda Python...
It sounds like you might want a python version manager, such as https://github.com/yyuu/pyenv
I can't vouch for this specific tool, but there are several similar utilities for ruby (rbenv, rmv) that are great.
OS X (or is it macOS now?) come with an installed version of Python. You almost certainly don't want to mess with that since updates to the OS will likely overwrite your changes. You may want to consider a tool called homebrew for OS X -- it lets you install specific versions of tools like python and manages them externally to the built-in versions.
Edit the .bash_profile
$ nano ~/.bash_profile
1. delete any reference to "export PATH=" to non-default-os python.
2. set up aliases to alternative python versions.
In other words, replace e.g. this:
# added by Miniconda3 4.0.5 installer
export PATH="/Users/PatrickT/miniconda3/bin:$PATH"
with this:
## create alias to miniconda/anaconda
## to make conda command accessible, first run: condainit
alias condainit='export PATH="/Users/PatrickT/miniconda3/bin:$PATH"'
## create alias to other python versions
alias pyconda='/Users/PatrickT/miniconda3/bin/python'
alias python3='/Library/Frameworks/Python.framework/Versions/3.5/bin:${PATH}'
## After installing pyenv with homebrew and run $ brew info pyenv
## set the following, according to the "caveat instructions":
if which pyenv > /dev/null; then eval "$(pyenv init -)"; fi
Source the .bash_profile:
$ source ~/.bash_profile
To access conda commands run this in the terminal:
$ condainit
$ conda info -e
To access the Python3 provided by conda, type:
$ pyconda
To access the Python3 installed via the dmg, type:
$ python3
To access the default OS-provided python (currently Python 2.7), type:
$ python
Among other sources, the following was particularly useful: Using two different Python Distributions
I'm completely new to Homebrew and Anaconda installation and I hope someone could help me out with the warning after executing brew doctor. I'm running on Snow Leopard 10.6.8. The warning is as follows:
Warning: "config" scripts exist outside your system or Homebrew directories.
`./configure` scripts often look for *-config scripts to determine if
software packages are installed, and what additional flags to use when
compiling and linking.
Having additional scripts in your path can confuse software installed via
Homebrew if the config script overrides a system or Homebrew provided
script of the same name. We found the following "config" scripts:
/Users/user.name/anaconda/bin/freetype-config
/Users/user.name/anaconda/bin/libpng-config
/Users/user.name/anaconda/bin/libpng15-config
/Users/user.name/anaconda/bin/llvm-config
/Users/user.name/anaconda/bin/python-config
/Users/user.name/anaconda/bin/python2-config
/Users/user.name/anaconda/bin/python2.7-config
/Users/user.name/anaconda/bin/xml2-config
/Users/user.name/anaconda/bin/xslt-config
I executed brew --config and the following shows the configuration (hope it helps w/ the issue):
HOMEBREW_VERSION: 0.9.4
ORIGIN: (none)
HEAD: (none)
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.6.8-i386
Xcode: 3.2.6
GCC-4.0: build 5494
GCC-4.2: build 5666
LLVM-GCC: build 2335
Clang: 1.7 build 77
X11: 2.7.4 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /Users/user.name/anaconda/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
Really appreciate your help. Thank you.
tl;dr: you can't really fix this but you can probably ignore it
Those scripts ending in -config provide information for other packages that want to link to them during installation. Let's take libpng for example. If brew (or anything really) compiles a package that depends on libpng it might execute libpng-config to find out some details about the library.
The problem is that brew brings its own version of libpng so if both are installed brew might pick up the wrong libpng-config when installing additional software.
You can do one of four things now:
Ignore the warning if you're confident that the stuff you install with homebrew will not conflict with the stuff that comes with anaconda.
Edit your ~/.bash_profile and remove anaconda from the PATH. If you do this you will have to specify the full path every time you want to run anaconda python.
Move those anaconda config files aside (out of your PATH, e.g. into a config subdirectory). This will likely prevent additional software from linking to anaconda components but should be ok if you intend to keep anaconda isolated.
Remove anaconda completely (just delete the folder) and install brew's version of python. This will also give you pip which should make it easy to reinstall most of the other packages that come with anaconda.
i.e.
brew install python
Then to install e.g. numpy, simply:
pip install numpy
(To make brew's python your default add export PATH="/usr/local/bin:$PATH" to your ~/.bash_profile)
I believe I've found a reasonably safe way to deal with this (if you are using the fish shell).
Install Anaconda but don't add to PATH
Add a symlink to the conda binary somewhere on your PATH (in my case ~/bin)
mkdir ~/bin
cd ~/bin; ln -s ~/anaconda3/bin/conda .
Add section like follows to ~/.config/fish
set -gx PATH $PATH ~/bin
source ~/anaconda3/etc/fish/conf.d/conda.fish
Note that this activate's the conda shell configuration for fish -- use conda activate some-env to switch into an anaconda environment rather than the bash-style source activate some-env. brew doctor should show that this issue no longer exists.
This setup lets you use the conda command to switch into conda-managed environments without worrying about leaky interactions between homebrew-managed python/dependency environments.
The one thing to remember is to avoid running homebrew when a conda environment is active as your path will be set for the conda environmnent and unsafe for homebrew usage.