I installed a pip package (Spyder) on Debian using pip3 install spyder=5.0.5. However, running spyder from the command line interface says that it's not found. I hacked a solution by adding an alias in my .bashrc that points to some obscure start.py file that launches Spyder.
I'm sure there must be a more orthodox way of invoking Spyder, presumably by editing the $PATH, but I'm not sure how.
As #phd said in the comments, I had to edit my $PATH to point to directory where pip3 installs its packages. Namely, I had to run export PATH="$HOME/.local/bin:$PATH" and that fixed the problem.
Related
Specs:
Macbook Air M1 Ventura
Visual Studio Code Version: 1.75.0
which brew
/opt/homebrew/bin/brew
which pip3
/opt/homebrew/bin/pip3
(which is a link to:
/opt/homebrew/Cellar/python#3.10/3.10.10/bin/pip3 )
tl;dr:
I don't have python installed through brew anymore, but only as pyenv (and only version 3.11.1) - my Mac native version is 3.9.6)
YET whenever I install something through the activated virtualenv it will re-create a folder in /opt/homebrew/lib/python3.10/site-packages.
I don't understand why it keeps fussing about python3.10 so much and how I can get packages installed to any other environment. It seems my pc is only the folder mentioned above.
What I tried:
Since a module (twarc-csv as part of the twarc2 package) didn't work anymore (when trying to run, it says Error: No such command 'csv'.; which twarc-csv in terminal also didn't find it), I started looking into my python environments. the developer of the package suggested it was related to versionings and recommend using pyenv.
I have to say that before installing pyenv I upgraded twarc (to be sure) in terminal with brew install twarc --upgrade (as I already figured my pip3 path and my python path didn't align see python mess) which automatically fetched python3.11.1 as a dependency for twarc for some reason. As a result besides the Mac native python version I now had python 3.11 and 3.10 installed.
Even when I explicitly ran 3.11 though (e.g. python3.11 -m pip install twarc --upgrade twarc-csv), packages would still be installed to this folder /opt/homebrew/lib/python3.10/site-packages though. So something was off.
I decided to go with the suggestion from said developer and try pyenv. I strictly stuck to this guide: clean pyenv environment and VSCode seemed to find my pyenv virtualenv installed python version. However even though which pip3 led to the virtual shims path, the packages were still installed to /opt/homebrew/lib/python3.10/site-packages
Ok, if I wouldn't really need this package to run, I would already have given up, but since things are the way they are... I decided to delete pyenv and reinstall python3 through brew.
As you might have figured by now, the cycle started from anew. I wanted to check into why this path is so dear to my setup /opt/homebrew/lib/python3.10/site-packages Visual Studio would also still indicate that python 3.10.10 is global, so I checked
import sys
import pprint
pprint.pprint(sys.path)
I checked this for 3.11 and 3.10 environment in VSCode
the one for 3.10 being
'/opt/homebrew/Cellar/python#3.10/3.10.10/Frameworks/Python.framework/Versions/3.10/lib/python310.zip',
'/opt/homebrew/Cellar/python#3.10/3.10.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10',
'/opt/homebrew/Cellar/python#3.10/3.10.10/Frameworks/Python.framework/Versions/3.10/lib/python3.10/lib-dynload',
'/opt/homebrew/lib/python3.10/site-packages']
the one for 3.11 being
'/opt/homebrew/Cellar/python#3.11/3.11.1/Frameworks/Python.framework/Versions/3.11/lib/python311.zip',
'/opt/homebrew/Cellar/python#3.11/3.11.1/Frameworks/Python.framework/Versions/3.11/lib/python3.11',
'/opt/homebrew/Cellar/python#3.11/3.11.1/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload',
'/opt/homebrew/lib/python3.11/site-packages']
plus my desktop, so this seems to be fine. Nevertheless even if I use interpreter 3.11 in VSCode it will still look for packages in python3.10 and not install them to 3.11
Now I checked $PATH and see what it says, and it still refers to pyenv it seems:
$PATH
zsh: no such file or directory: /Users/myusername/.pyenv/shims:/Users/myusername/.pyenv/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/go/bin:/Library/Apple/usr/bin
So how do I clean that up?
Also, how do I get things to run correctly? I do not understand that affection to the sitepackages 3.10 at all.
Update:
I am wondering whether my zprofile, zshrc or bashrc or bash_profile files have to do with it.
That's how they look:
(bashrc is empty)
bash_profile
export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"
zprofile
# Set PATH, MANPATH, etc., for Homebrew.
eval "$(/opt/homebrew/bin/brew shellenv)"
zshrc
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PATH"
if command -v pyenv 1>/dev/null 2>&1; then
eval "$(pyenv init -)"
fi
I have Spyder, clean Win10 installation, ver. 4.2.3.
When I run command pip, it gives message:
Note: you may need to restart the kernel to use updated packages.
C:\Users\UserName\AppData\Local\Programs\Spyder\Python\python.exe: No module named pip
I restarted Spyder, Win10, nothing helps.
How to fix it?
Thanks.
(Spyder maintainer here) We don't provide pip in our Windows app to prevent people breaking Spyder by installing any kind of packages with it.
The best way to use other packages that don't come with our app is to install Miniconda, create a conda environment after that with the packages you want to use and spyder-kernels, and finally connect Spyder to that env.
If you have python 3.4+ then pip should be installed with python.
To check that, you can run
pip help
in your windows command line.
However, if it isn't the case then download the get-pip.py file and run
python get-pip.py
and the pip installation should start. You can use pip help to verify this.
Another source of the problem might be that pip isn't listed in your PATH variables and thus isn't recognized by your command line.
I'm running a fresh installed OctoPi image (0.18.0). I added pip to my PATH in .bashrc file and sourced it but when I try to run pip I'm getting -bash: pip: command not found error.
When I run /home/pi/oprint/bin/pip, pip is working properly.
My path:
pi#octopi:~ $ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games:/home/pi/oprint/bin/pip:
You added the full path of the executable to the path, but you're only supposed to add the directory of the executable. Every exectuable of said directory is then directly available without the directory prefix.
In other words .. instead of /home/pi/oprint/bin/pip you should add /home/pi/oprint/bin/ to the path.
I always recommend using the Python executable to locate the pip executable for you. This way, you know the right version of pip is being used to install packages that are compliant with your Python version.
$ python -m pip install <the_package_you_want>
It is really easy to end up with mismatched versions otherwise!
I'm trying to get started with a book called "TDD with Python", OS W10. As part of the setup it wants you to install virtualenvwrapper. The recommendation is to use GitBash in Windows... but I've been using Cygwin for quite a bit and didn't like GitBash when I looked at it some time ago.
Python version is 3.6. I installed virtualenvwrapper by going
pip install virtualenvwrapper
This seemed to work OK.
Trying to add the relevant setup line to my .bashrc did not go so well:
echo "source virtualenvwrapper.sh" >> ~/.bashrc
source ~/.bashrc
output:
/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.
At least this proves that virtualenvwrapper.sh is being run...
In fact there is no such directory as /usr/bin ... so I added a preceding line in .bashrc pointing to what I hoped might be what it might be wanting to see for this VIRTUALENVWRAPPER_PYTHON environment variable (do we call them that in Linux?).
VIRTUALENVWRAPPER_PYTHON=/cygdrive/d/apps/Python/Python36/Lib/site-packages/virtualenvwrapper
Now I get
bash:
/cygdrive/d/apps/Python/Python36/Lib/site-packages/virtualenvwrapper:
Is a 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=/cygdrive/d/apps/Python/Python36/Lib/site-packages/virtualenvwrapper
and that PATH is set properly.
Main question: what is VIRTUALENVWRAPPER_PYTHON meant to point at? An executable file? Any clues to help me recognise the desired target would be much appreciated!
POST-ANSWER ENLIGHTENMENT Just in case anyone stumbles this way, just to let you know: after phd gave me the answer to this I found other problems.
Eventually I managed to install virtualenvwrapper by doing this:
pip uninstall virtualenvwrapper
... use the latest Cygwin setup .exe to install pip3. Note the 3!
then go
pip3 install virtualenvwrapper
echo "source virtualenvwrapper.sh" >> ~/.bashrc
source ~/.bashrc
... success! but quickly followed by another puzzle: see here.
VIRTUALENVWRAPPER_PYTHON should point to python binary: /usr/bin/python, e.g.
I'm having a little trouble with virtualenv on Mac OS X Yosemite. After I couldn't run virtualenv at all first, I installed Python 3 via brew (previously I installed it via the package on python.org). I linked this installation of python3, updated pip and ran pip3 install virtualenv. When I try to run virtualenv (e.g. $ virtualenv --python=python3 ../virtualenv), I get the following error message.
Traceback (most recent call last):
File "/usr/local/bin/virtualenv", line 7, in <module>
from virtualenv import main
File "/usr/local/bin/virtualenv.py", line 7, in <module>
from virtualenv import main
ImportError: cannot import name 'main'
Can anybody help me with this?
After my upgrade to Fedora 32 I had the same issue which lead me to this question:
ImportError: cannot import name 'main' from 'virtualenv'
In my case I actually seemed to have both /usr/local/bin/virtualenv as well as $HOME/.local/lib/python3.8/site-packages/virtualenv/__init__.py.
Removing the user virtualenv version and reinstalling it into the system with root fixed the issue:
pip uninstall virtualenv
sudo pip install virtualenv
Your virtualenv executable /usr/local/bin/virtualenv is importing the virtualenv package /usr/local/bin/virtualenv.py. My guess is that package is not the one the executable should really be importing. The reason it is choosing that one is because it is in the same directory.
First, check where the real virtualenv package is. In the python3 terminal:
>>> import virtualenv
>>> virtualenv.__file__
If it is not /usr/local/bin/virtualenv.py, then the simplest way to get /usr/local/bin/virtualenv to import it instead of /usr/local/bin/virtualenv.py is to delete /usr/local/bin/virtualenv.py (or so you can easily undo this if it doesn't work, simply rename virtualenv.py to something else like xvirtualenvx.py).
I received this error after upgrading Ubuntu 18.04 LTS to 20.04 LTS. So there were two problems all at once. First the python version was still running 2.x and doing a simple update or try to uninstall (apt-get remove virtualenv) of virtualenv did not help at all. But I found a solution. First let 20.04 LTS 'know' the times of using old python is over:
sudo apt-get install python-is-python3
Then test it and open a console to get the version string with python -V; by now it should be showing something like Python 3.8.5. Fine.
Next step is to solve the virtualenv problem. I tried to find out, which executable was run with which virtualenv and it showed: $HOME/.local/bin/virtualenv. Hmmkay, somehow the system wasn't using the /usr/bin/virtualenv executable. I thought maybe I let the directory become invisible (a.k.a. renaming) and maybe the system will go on a hunt for an alternative virtualenv running:
mv $HOME/.local/bin/virtualenv /home/USER/.local/bin/virtualenv_OLD
Then I simply changed into a playground-directory and ran virtualenv donaldknuth and behold - it worked. To be sure I ran another which virtualenv and the system returned a /usr/bin/virtualenv. Last check to do was activating the new virtual environment:
source $HOME/playground/donaldknuth/bin/activate
The terminal changed and it worked fine. Solution
EDIT:
Based on Pierre B.'s suggestion you may have to restart your Shell. The command hash -d virtualenv will delete the stored location of virtualenv from the shell's cache and determine the correct path right now. (Sources: https://www.computerhope.com/unix/bash/hash.htm, https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables)
Similarly to some others here, I had multiple installations of virtualenv. Not sure where the extra one came from, but I had these two:
/usr/local/bin/virtualenv
/usr/bin/virtualenv
One is from apt install of virtualenv, the other from pip install of virtualenv.
This happened when upgrading to Ubuntu 20.04.
On Linux Mint 20, I had to switch default Python interpreter to python3
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1
Then remove existing virtualenv and reinstall via pip and python3:
rm ~/.local/bin/virtualenv
apt remove python3-virtualenv
sudo pip install virtualenv