I am working in a virtual environment in Python 3.I need to use a 3 party module "mglearn" and I copy it to my virtual environment's lib/:
/home/abigail/environments/my_env/lib/python3.5/site-packages/mglearn
However, in ipython command line, it can't find the module name:
In [1]: import mglearn
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
<ipython-input-1-e19748f92cd9> in <module>()
----> 1 import mglearn
ImportError: No module named 'mglearn'
It should find it. Right?
Then I checked my sys.path:
In [4]: print(sys.path)
['', '/usr/bin', '/usr/lib64/python35.zip', '/usr/lib64/python3.5', '/usr/lib64/python3.5/plat-linux', '/usr/lib64/python3.5/lib-dynload', '/usr/lib64/python3.5/site-packages', '/usr/lib/python3.5/site-packages', '/usr/lib/python3.5/site-packages/IPython/extensions', '/home/abigail/.ipython']
Why does "sys.path" only contain directories starting from the root /, not my virtual environment? How can I get that module to be searched by Python?
Edited:
[abigail#localhost bin]$ ll activate
activate activate.csh activate.fish
[abigail#localhost bin]$ ./activate
bash: ./activate: Permission denied
[abigail#localhost bin]$ sudo ./activate
sudo: ./activate: command not found
Strange! why is that?
VirtualEnv creates a clone of a Python installation and bakes an additional path into sys.path that point to the site-packages directory of a given virtualenv.
When you launch your IPython, it is likely installed in your main Python installation and does not know about any additional virtual environments you have created.
If you install IPython into a virtual environment, it will know about the site-packages location for that virtualenv. Try and run:
which ipython
Then look at your ipython script and you will see it begin with either:
#!/usr/bin/python
or:
#!/home/abigail/environments/my_env/bin/python3
The first indicates a globally installed ipython and the second is an ipython that has been installed into a specific virtualenv.
FYI, you can add paths to a Python interpreter by exporting the PYTHONPATH environment variable:
```export PYTHONPATH=/home/abigail/environments/my_env/lib/python3.5/site-packages```
This would let you use a globally installed IPython with your virtualenv. However, the typical way to do this would be to install a second copy of IPython in your virtualenv and use that copy.
```/home/abigail/environments/my_env/bin/ipython```
The activate shell commands for a virtualenv only do two things:
Add the virtualenv Python interpreter to your PATH. So when you type python3 you run /home/abigail/environments/my_env/bin/python3 instead of /usr/bin/python3. It is this binary at /home/abigail/environments/my_env/bin/python3 which will automatically include the /home/abigail/environments/my_env/lib/python3.5/site-packages location on the sys.path.
Change your PS1 environment variable so your terminal has a prompt to remind you which virtualenv you are working in.
It is up to you to use the activate shell script or not (as it's just very simple helper script, you can adjust environment in whatever way makes sense for yo). If you are only using one virtualenv, you can add exports to your ~/.bashrc file instead, e.g.:
```export PATH=/home/abigail/environments/my_env/bin/:$PATH```
Would automatically make python3 run your virtualenv Python the same as running source activate within your virtualenv.
Generally speaking for a virtual environment you will want to do an install to get the module you are looking to import to pre-pend correctly in your path variable at virtual environment activation time. Consider trying this:
Since it looks like you already have a virtual environment set up, and it looks like you are using some form of Unix/Linux:
/home/abigail/environments/ $ source my_env/bin/activate
You should then see your terminal look something like:
(my_env) /home/abigail/environments
that means you have an active virtual environment.
Next you should install the module you want. I am assuming that module is available via pip install.
(my_env) /home/abigail/environments $ pip install mglearn
This should get you all set up. When you check your sys path you should now see at the front of it your virtual environement python stuffs. And your import error should go away.
You may need to delete out the copy of mglearn you dropped into the directories manually if things get stuck.
Related
I am running VSCode on Windows 10. I've set up a virtual environment and have installed a number of packages to the local site library.
I've activated my environment (The terminal prompt shows a .venv string)
However, when I attempt to import any of my local modules, I get an 'Module not found'
error.
Doing a pip list shows that the modules do exist in the virtual env.
I've verified that I'm running the Python executable in the virtual environment.
Printing sys.path gives the following output:
['', 'C:\Users\User\AppData\Local\Programs\Python\Python39\python39.zip', 'C:\Users\User\AppData\Local\Programs\Python\Python39\DLLs', 'C:\Users\User\AppData\Local\Programs\Python\Python39\lib', 'C:\Users\User\AppData\Local\Programs\Python\Python39', 'C:\Users\User\Documents\mednotes\.venv', 'C:\Users\User\Documents\mednotes\.venv\lib\site-packages']
The AppData path is, I believe the global Python namespace. Why is this even in my
sys.path in my local virtual env? I added the last two paths manually to see if this
would fix anything but no luck.
I'm really stuck here. Anybody have any suggestions for fixing this?
Thanks
Are you sure pip installed them to the correct place? Can you see the packages you installed under the C:\Users\User\Documents\mednotes\.venv\lib\python3.9\site-packages folder?
I would double-check where python3 and pip are getting picked up from. Try where python3 and where pip.
A virtual environment is a built-in way to create an environment to isolate the packages you install per workspace.
When you use a virtual environment, it will isolate the local package.
You can use shortcuts "Ctrl+Shift+P" and type "Python: Select Interpreter" to choose the correct interpreter.
Another way is to use conda install packageName command to install the package in the virtual environment.
Presently I'm using Python on a Windows system. I installed Python 3.10 from Anaconda and also the Pycharm IDE. I have ensured that Python is in the correct path in the environment variable. I have also replicated this problem using two different versions of Python, 3.10 and 3.9.
Very simply, in PyCharm, I open a terminal and type
conda install -c numpy numpy.
Then, I write a new "main.py" script. I have one line: "import numpy". I receive the error:
Traceback (most recent call last):
File "C:\Users\---\PycharmProjects\pythonProject3\main.py", line 17, in <module>
import numpy
ModuleNotFoundError: No module named 'numpy'
What am I doing wrong?
Going on advice from a friend, I created a new PyCharm project sitting not in my user directory but on the C: drive, and got the same error. Finally, when trying to re-install the package using either using either pip or conda, I get this message:
# All requested packages already installed.
You have 2 versions of Python:
Default Python (used everytime you open your command prompt and type python or python3)
Anaconda is installing packages in a virtual environment, using it's own Python (it is located in a different path)
You can see the path of your installed python using python -c "import os, sys; print(os.path.dirname(sys.executable))"
You have 2 Options:
Configure the PyCharm in order to use the anaconda Python. https://www.jetbrains.com/help/pycharm/configuring-python-interpreter.html#view_list
Open a command prompt in the project's folder (you can do it easily using PyCharm). Type conda env list. This will show you all available anaconda virtual environments. Choose 1 of them and type conda activate <env_name>, where <env_name>=the name of the environment. Then, run your program using python <name_of_your_program>
You can see the paths where the anaconda environments and packages are installed using conda info
There main reason for this is
You are running your main.py in different environment rather than where you installed numpy.
If you trying to run it via cmd use this method
Check which environment you are in right now. refer this and
this. But the most easiest way to do this is use where command
in windows cmd. C:\> where python or C:\> where python3. You will
get the path of activated interpreter.
list conda envs - conda env list
activate conda env - conda activate <env name>
then run this command. pip freeze . and check is there numpy in
the list. If not you have to find and activate the environment where
you have installed numpy.
If you want to run it in pycharm
Refer this on how to change pycharm interpreter.
https://www.jetbrains.com/help/pycharm/configuring-python-interpreter.html
Many things can cause this, usually its one of these
You may have to restart your terminal, or IDE if running in there, after installing a package to "refresh" the environmental path
The package is not in the environmental path
I need to use the autogui module to do something in Python. When I run the script, it says that it can't find the autogui module so I installed it with
pip install autogui.
But when I run the script again it still says me this module doesn't exist.
Method 1:
You're probably having trouble setting up your correct Python Interpreter and working within it,try the following in VSCode.
Ctrl + Shift + p
And enter the following in the field.
python: select interpreter
Select the desired environment and reinstall PyAutoGui
Method 2:
Creating a virtual environment for your project where all your packages will be installed and will be isolated from others, and will have no import errors since it's an environment specifically for the project that you're working on.
I assume you use Windows, so open the command line in your working directory, or open your working directory in VSCode and enter the following in the command-line tool that is provided within VSCode.
The Python installers for Windows include pip. You should be able to access pip using:
py -m pip --version
You can make sure that pip is up-to-date by running the following
py -m pip install --upgrade pip
Installing virtual environment
py -m pip install --user virtualenv
Creating a virtual environment
py -m venv env
The second argument is the location to create the virtual environment. Generally, you can just create this in your project and call it env.
venv will create a virtual Python installation in the env folder.
Finally, to activate the environment run the following command
.\env\Scripts\activate
That will activate your environment.
pip install pyautogui
Make sure to change your interpreter to the one that you just created in the env/bin folder and run your code, or you could just enter the path to the *python file located in the env/bin folder.
Try pyautogui - I had the same problem. Instead of autogui, write `pyautogui. Or, if you are running python3 or higher then try:
pip3 install pyautogui.
I'm creating a Django app that requires me to use python2.7.6 . My system has python3.4.1 installed so I have to use a virtualenv with python2.7 installed. I installed such a virtualenv using Pycharm and named it django_python_2.7 but when I activate it in the terminal and run "python", it still shows that it's using system's python3.4.1:
here is what I did:
Activate the environment:
source django_python_2.7/bin/activate
Run python, and it shows:
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 00:54:21) ---> this is the system level python and not the one installed in virtualenv
However, when I run which python, it shows the correct path that points to virtualenv's python version:
/Users/calvinmwhu/....../django_python_2.7/bin/python
When I explicitly run the python version installed in that virtualenv:
django_python_2.7/bin/python
it shows the correct version:
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
I have no idea what's going on. I'm developing this app in Pycharm IDE but I really like executing commands in the terminal . But in the terminal the virtualenv is not using the correct version of python..Why does running a simple "python" command in the virtualenv still default to the system's python ?
Could anyone provide some hints? Is it necessary to change the PATH variable to make it contain the path to the virtualenv's python?
If you want to change the PYTHONPATH used in a virtualenv, you can add the following line to your virtualenv's django_python_2.7/bin/activate file
export PYTHONPATH="/path/to/python"
export OLD_PYTHONPATH="$PYTHONPATH"
To restore to its original value on deactivate, you could add following line to your django_python_2.7/bin/postdeactivate script.
export PYTHONPATH="$OLD_PYTHONPATH"
Otherwise, create new env using
virtualenv -p /usr/bin/python2.7 django_python_2.7
I discovered the same problem...
and like #skyline75489 mentioned:
I forgot that i had stated an alias to my python3 executable a time ago.
I found it in my .bash files in my home directory and removed it.
Everything worked out fine again with my virtual environment.
If you changed the path to your venv or ranamed any of the parents folders of your venv directory, then this will break the configured paths, if that is case you have two options:
recreating it
Create a requirements.txt file using: pip freeze > requirements.txt
Delete the venv directory: rm -r old-vnev/
Create a new virtualenv with correct name: python -m venv new-venv
Activate new virtualenv: source new-venv/bin/activate
Install packages from requirements.txt: pip install -r requirements.txt
Another simpler way
search for all occurences of the string old/path/to/your/venv/
replace them with correct/path/to/your/venv/
after that source new-venv/bin/activate will work as intended again.
Hope this help!
In case it helps anyone else: if you changed the path to your venv folder (such as changing the parent folder), this will happen. This was my issue.
Recreating your virtualenv will fix it, as you should hopefully have a requirements.txt created to rebuild your virtualenv.
This might have even been the root cause for OP.
Double check your paths. I had an issue like this recently where running which python from within the activated virtualenv would still return the default system version (/usr/bin/python). However, if I ran the scripts specifying the binaries directly (./venv/bin/python, etc) from within the virtualenv, it worked as expected so it appeared all the dependencies had been installed correctly.
The issue was that I had moved the parent virtualenv directory after building everything. This meant all the virtualenv paths pointed to the original location which was no longer valid, and python correctly defaulted to the default system binary.
I use a bash script like this:
$ source venv/bin/activate
$ alias vpython=$VIRTUAL_ENV/bin/python3
and use vpython when wanting to use the python executable within the virtual environment. A nice way to check which executable you are actually using within python is the following:
>>> import sys
>>> print(f'executable \033[0;33;40m{sys.executable}\033[0m')
In my situation after system update symbolic link from the virtualenv was somehow broken and it switched to default system python version. The solution was to replace symbolic link by the correct one.
Deactivate virtual env if you are inside by:
deactivate
Change virtualenv python symbolic link:
ln -s /your/wanted/python/bin/python /your/virtualenv/bin/python
Start virtualenv again and it should use correct python version.
If you are not sure where is your python, then you can localise it by:
which python3
I had a similar problem. But I had it because I had moved my env folder to another place. So, if you did so, just go to activate file in bin folder and change VIRTUAL_ENV="CurrentPathToYourEnvFolder" (it's 40th line in file)
I am working in ubuntu. I have installed the django==1.3 in root earlier. Now I created local virtual environment name as local_env using virtualenv. Then I activated the local_env using source command.But I didn't install the django in this local_env environment. When I try to create the django sample project using
django-admin.py startproject sampleproject
it is working perfectly. My question is,It didn't prevent the local_env from the root environment ?. I mean it didn't raise the error like django-admin.py command didn't found. Please put the comments if any doubts.
django-admin.py is in the OS path. When you try executing it inside your virtual environment, the python will look into it's VE's sys.path and if not found it will search through the OS path, found it from the root environment and so there were no errors shown.
According to the docs, the django-admin.py command is installed on your system path, so if the virtualenv doesn't find this command, it will probably look in the global sys path and find a match.
If you want to use a different version of django to the one installed on your sys path, you will need to install it in your vritualenv using a package manager like pip and this will then take precedent over the global django-admin.py
To make sure you're doing this right, load your the virtualenv using
dhanna#dhanna:~$ source local_env/bin/actviate
If successful, your prompt should have the virtualenv name at the beginning - eg
(local_env)dhanna#dhanna:~$
Note that if you activate the virtualenv in one shell, but run the python interpreter inside a separate shell, you will be using the global interpreter and therefore have the global django-admin.py module available.
Next you'll want to install the django module
(local_env)dhanna#dhanna:~$ pip install django
To check if django is installed inside your virtual env, you can use the package management tool pip and pass the freeze argument
(local_env)dhanna#dhanna:~$ pip freeze
Now you can use the virtualenv's version of django-admin.py
(local_env)dhanna#dhanna:~$ django-admin.py startproject sampleproject