I get the following message when trying to run virtualenv . --no-site-packages
You are attempting to install a package to a directory that is not
on PYTHONPATH and which Python does not read ".pth" files from. The
installation directory you specified (via --install-dir, --prefix, or
the distutils default setting) was:
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/
and your PYTHONPATH environment variable currently contains:
''
However, when I echo my PYTHONPATH, I see the path from the default setting:
/usr/local/python-3.3.1/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/:/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/
So my PYTHONPATH does contain the directory I am installing to.
Anyone have any ideas what is going on?
Turns out I needed to use virtualenv-3.3, not virtualenv.
Related
After updating macOS Monterey today to 12.6 all my Python projects/scripts have stopped working.
Checking the symlink of a Python binary in one of my project's venv, I see the original to be:
/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3.9
which is not in path list!? 🤔
Installed with the macOS update today?
it seems that all the symlinks to Python in the virtual environments of all of my VS Code projects now point to the binary above, and none of the projects work anymore, all with ModuleNotFoundError.
How can I get all my projects to work again?
Background/details:
.bash_profile:
# Setting PATH for Python 3.8
PATH="/Library/Python/3.8/bin:${PATH}"
export PATH
.zprofile:
PATH="/Library/Python3.9/bin:${PATH}"
export PATH
eval "$(/opt/homebrew/bin/brew shellenv)"
.zshrc:
export PATH=$PATH:/Users/xxxx/Library/Python/3.8/bin
The scripts run with venv activated ((venv)...), confirmed with which python which accurately returns the path of Python in venv (though symlinked to the weird path).
When trying to (re)install those libraries, with venv still active, they get installed in root Python with following warning:
WARNING: The scripts f2py, f2py3 and f2py3.9 are installed in '/Users/xxxxxx/Library/Python/3.9/bin' which is not on PATH.
Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
I'm using /bin/zsh when run in VS Code. Same from stand-alone terminal window.
I shared Bash above as listed in paths.
tried:
echo $PATH
returns (edited for readability):
/opt/homebrew/bin:
/opt/homebrew/sbin:
/Library/Python3.9/bin:
/usr/local/bin:
/usr/bin:
/bin:
/usr/sbin:
/sbin:
/usr/local/MacGPG2/bin:
/Library/Apple/usr/bin:
/Users/xxxx/Library/Python/3.8/bin
notes:
the last path (/Users/..) seems to be the one used by Bash but not Zsh/VS Code/. This was working as is before the update though.
need to add missing path: /Users/xxxx/Library/Python/3.9/bin
checking paths one by one:
/opt/homebrew/bin: no Python binary in folder
/opt/homebrew/sbin: no Python binary in folder
/Library/Python3.9/bin: folder Python3.9 does not exist
/usr/local/bin: /usr/local/bin/python found +++
/usr/bin: /usr/bin/python3 found +++
/bin: no Python binary in folder
/usr/sbin: no Python binary in folder
/sbin: no Python binary in folder
/usr/local/MacGPG2/bin: no Python binary in folder
/Library/Apple/usr/bin: no Python binary in folder
/Users/xxxx/Library/Python/3.8/bin: no Python binary in folder 🤔
not returned with echo $PATH / need to be added: /Users/xxxx/Library/Python/3.9/bin also no Python binary in folder 🤔
not listed but symlinked now in all projects: /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3.9
I had the same issue in VS Code running notebooks. I uninstalled and reinstalled the Jupyter extension. Then when attempting to run a notebook for the first time again, there is a prompt to install jupyter notebook. Once done, all the notebooks are running fine again for all the environments I am using.
first, I'll describe the problem. then I'll describe what I've tried. note that I am a novice in working with environment variables.
the problem:
In Spyder, I get a "module not found error" from certain libraries I've installed via pip, including tables and tensorflow. However, in Visual Studios these modules are successfully imported.
what I've tried
inspecting the directories the VS environment looks in, then adding these to $PATH in Spyder via the PYTHONPATH manager. To determine the directories VS looks in, I typed "echo $PATH" in the VS terminal emulator. I got a list of paths (see below). I then went to Spyder and added each of these paths via the PYTHONPATH manager.
found the locations of "tensorflow" by searching for "tensorflow" in Finder. I then went to Spyder and added each of these paths in PYTHONPATH manager.
outcome: PYTHONPATH and PATH do not change
In the terminal emulator in Spyder, I check to see if PYTHONPATH and PATH are updated but they are not.
in the python terminal emulator, this is the output:
!echo $PYTHONPATH
/Applications/Spyder.app/Contents/Resources
!echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
For reference, in the VS terminal emulator the PATH and PYTHONPATH variables are as follows:
(base) rahel-gerson:~ rahelmizrahi$ echo $PYTHONPATH
(base) rahel-gerson:~ rahelmizrahi$ echo $PATH
/Library/Frameworks/Python.framework/Versions/3.9/bin:/Library/Frameworks/Python.framework/Versions/3.8/bin:/Users/rahelmizrahi/opt/anaconda3/bin:/Users/rahelmizrahi/opt/anaconda3/condabin:/Users/anaconda3/bin:/anaconda3/bin:/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands
parsed version:
note that I couldn't find some of these paths, like "/anaconda3/bin:". Perhaps I parsed the list incorrectly? (I thought that after a colon is a new path)
/Library/Frameworks/Python.framework/Versions/3.9/bin:
/Library/Frameworks/Python.framework/Versions/3.8/bin:
/Library/Frameworks/Python.framework/Versions/3.7/bin:
/Users/rahelmizrahi/opt/anaconda3/bin:/Users/rahelmizrahi/opt/anaconda3/condabin:
/Users/anaconda3/bin:
/anaconda3/bin:
/usr/local/bin:/usr/bin:
/bin:
/usr/sbin:
/sbin:
/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:
/Library/Frameworks/Mono.framework/Versions/Current/Commands
-bash: /usr/local/bin/python3: No such file or directory
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=/usr/local/bin/python3 and that PATH is
set properly.
The error comes from a broken installation of virtualenvwrapper. It seems you've installed virtualenvwrapper using /usr/local/bin/python3 but later removed that python.
The error comes from ~/.bashrc. Edit it, search for something like source virtualenvwrapper_lazy.sh or . virtualenvwrapper.sh and comment out or remove the line.
1. Check virtualenvwrapper is installed.
2. Open your .bashrc file.
3. Run the below commands:
export WORKON_HOME=$HOME/.virtualenv
source /usr/local/bin/virtualenvwrapper.sh
workon <virtual_env_name_of_your_choice>
which python
4. Check the python version.
5. If you want to change the python of your virtualenv, then follow the steps below:
vi .bashrc or vi .zshrc
alias python=python3
6. Open a new terminal.
which python
workon
which python
You are all set with virtualenv set to python3 by default.
Python 3.6 has been installed (using the Cygwin setup .exe file, update, etc.). The executable is located in /bin/ ... or is it located in /usr/bin/? Cygwin ls command shows that /usr/bin exists... but on Windows this directory is non-existent. Also the contents of both directories are identical, including if I change a filename... but I haven't as yet found a symlink (in /usr or in / ) to explain this!
I'm struggling to get virtualenvwrapper installed (this is part of a preparation required to follow along with a book, TDD With Python).
I just overcame a first hurdle (eventually) by realising I had to install virtualenvwrapper using pip3, not pip! ... I feel like I'm in at the deep end.
So I did:
pip3 install virtualenvwrapper
echo "source virtualenvwrapper.sh" >> ~/.bashrc
source ~/.bashrc
... then I did
mkvirtualenv --python3=`py -3.6 -c"import sys; print(sys.executable)"` superlists
(NB "python3" is the correct name of the symlink which points to the Python3 executable in /bin/; there is a "python" symlink but that points to Python2.7)
And I got:
Requested Python version (3.6) not installedUsing base prefix '/usr'
New python executable in
/home/Chris/.virtualenvs/superlists/bin/python3Also creating
executable in /home/Chris/.virtualenvs/superlists/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating
/home/Chris/.virtualenvs/superlists/bin/predeactivate
virtualenvwrapper.user_scripts creating
/home/Chris/.virtualenvs/superlists/bin/postdeactivate
virtualenvwrapper.user_scripts creating
/home/Chris/.virtualenvs/superlists/bin/preactivate
virtualenvwrapper.user_scripts creating
/home/Chris/.virtualenvs/superlists/bin/postactivate
virtualenvwrapper.user_scripts creating
/home/Chris/.virtualenvs/superlists/bin/get_env_details (superlists)
Anyone know what's going on? How do I get the system to recognise that Python3.6 is actually installed?
Later Or... am I being very dense? Maybe making a virtual environment using this module always involves installing a new Python executable?
Later still I'm still not clear about this... but it isn't stopping me from using virtualenv and virtualenvwrapper and generally getting on with the book. Despite complaining Python doesn't exist the setup appears (as far as I can tell!) to be using the symlinks under the directories in directory .virtualenv/ to one of the Python symlinks in /bin/ ...
About first question
/usr/bin and /usr/lib are by default also automatic mount points
generated by the Cygwin DLL similar to the way the root directory is
evaluated. /usr/bin points to the directory the Cygwin DLL is
installed in, /usr/lib is supposed to point to the /lib directory.
https://cygwin.com/cygwin-ug-net/using.html#mount-table
For the second, to check if phyton3 is installed
$ cygcheck -c python3
and as mentioned by phd the py command is not a cygwin one, so probably you are mixing something.
I have a VPS running Centos6, which has Python2.6 pre-installed. I have installed Python3.6 on this path
/usr/local/bin/python3.6
I have installed virtualenv using pip which is at
/usr/local/bin/virtualenv
I then created a virtualenvwrapper.sh file under /etc/profile.d (I have been advised this is what I need to do) which is generating an error on start up:
/usr/bin/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=/usr/bin/python and that PATH is
set properly.
virtualenvwrapper is located at /usr/local/bin/python3.6/site-packages
As I am novice using Linux I didn't think the code in the file virtualenvwrapper.sh (under /etc/profile.d)
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
source /usr/local/bin/virtualenvwrapper.sh
UPDATE
I have now edited the virtualenvwrapper.sh file under /etc/profile.d as follows
export WORKON_HOME=$HOME/.virtualenvs
export PROJECT_HOME=$HOME/Devel
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python3.6
export VIRTUALENVWRAPPER_VIRTUALENV=/usr/local/bin/virtualenv
source /usr/local/bin/virtualenvwrapper.sh
This has worked fine - I can now run the virtualenvwrapper commands. Is it pk that all of the start up files have been placed in the .virtualenvs folder (eg initalize, postactivate etc) - which means that when I create a virtualenvironment, that will be placed alongside these files? Is there a better way to do this?
Many thanks
Answering your second question: this is how virtualenvwrapper works. It puts global initialization files into ~/.virtualenvs; these files will be run (sourced, actually) for every virtual env. Also there will be separate initialization files for every virtual env.
Having all virtual envs in ~/.virtualenvs helps virtualenvwrapper to manage all envs.