I input python in cmd and it shows a warning:
C:\Users\sky>python
Python 3.8.8 (default, Apr 13 2021, 15:08:03) [MSC v.1916 64 bit (AMD64)] :: Anaconda, Inc. on win32
Warning:
This Python interpreter is in a conda environment, but the environment has
not been activated. Libraries may fail to load. To activate this environment
please see https://conda.io/activation
Type "help", "copyright", "credits" or "license" for more information.
>>>
I cannot use pip install any packages, I thought maybe that's the problem. So I checked the information at the link:https://conda.io/activation
and followed the instruction:
c:\Anaconda3\Scripts\activate base
It said 'system cannot find the path'. I searched for the files in that path and found two of them are named 'activate'. So I input
c:\Anaconda3\Scripts\activate
but still,'system cannot find the path'.
How to activate the conda environment? I really need some help. Thanks
In a clean Anaconda installation you should have condabin only, e.g.
C:\Anaconda3\condabin
on your system path. To activate the base environment from the command prompt you use
C:\> conda activate
(base) C:\>
This will add the following folders to your system path too:
C:\Anaconda3;
C:\Anaconda3\Library\mingw-w64\bin;
C:\Anaconda3\Library\usr\bin;
C:\Anaconda3\Library\bin;
C:\Anaconda3\Scripts;
Only now you you are ready to run python and import all your packages properly.
The same thing typically happens when you select Anaconda prompt from your programs menu.
Related
After installing miniconda, my python modules stopped working, throwing ModuleNotFoundError. From what I can tell, miniconda changed my default environment settings. I checked both .bash_profile and .bashrc and updated the files to give conda the lowest priority. This fixed my default python version but didn't fix any of the broken modules.
Next I checked my PYTHONPATH with python3 -c "import sys;print(sys.path)". I discovered that the PYTHONPATH consisted entirely of conda python paths instead of the python version I had called. For reference, my default python version should be 3.8 (now set in .bashrc), and the conda version is 3.9.
['', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python39.zip', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload']
I then manually changed my PYTHONPATH in the .bashrc file to include the appropriate library paths. After reloading .bashrc:
['', '/Users/Ghoti/venv/3.8/lib/python3.8/site-packages', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/site-packages', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python39.zip', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9', '/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/lib/python3.9/lib-dynload']
My modules now work! However, I haven't been able to figure out how to stop the conda 3.9 libraries from being appended to my PYTHONPATH. In addition, my printed python version is wrong.
Ghoti$ python --version
Python 3.9.6
Ghoti$ which python
/Users/Ghoti/venv/3.8/bin/python
I was able to "fix" my ModuleNotFoundError problem. However, the solution is only temporary. If I ever need to switch python version/environment, I'll have to go through the process again. I'd like to figure out what is overriding my PYTHONPATH, causing it to call conda 3.9 libraries, and fix the python version irregularity. I've considered that there might be a script/process running in the background, but I haven't found any related to conda/miniconda. I've also been looking for a python setting/config file. No luck. Any suggestions on where I should look?
Edit - Did some more digging. It looks like my version 3.8 python executable was entirely overwritten, and the only existing python installation that is version 3.9.6 is in my "/usr/bin". The two conda environments have versions "3.9.12" and "3.8.13". I feel more confident the issue isn't due to conda, but unsure what could have caused the problem.
Final Edit
I don't think the problem was miniconda. I did start having problems within a few days of using miniconda and I original assumed that it just took me a while to notice the issues. However, I now think that my virtual environment was created using a shared python. Problems were noticed on the same day that I connected to network. The shared python version changed, and that broke my environment. I don't have a solution to salvage the broken environment, but rebuilding it from scratch shouldn't take too long.
Sounds like you only want to use conda when you explicitly need it, in other words, the default Python is the system Python.
If that's the case, you should disable the auto-activation of the base environment:
conda config --set auto_activate_base false
<restart shell>
Now you'll need to explicitly activate the conda environment before you can use the conda Python:
$ python
Python 3.10.6 (main, Aug 11 2022, 13:49:25) [Clang 13.1.6 (clang-1316.0.21.2.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ conda activate base
(base) $ python
Python 3.9.12 (main, Jun 1 2022, 06:36:29)
[Clang 12.0.0 ] :: Anaconda, Inc. on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
I have ubuntu 2022LTS with python 3.10.4 and numpy installed.
But since I installed miniconda, I cannot get back to my original system installation of python even when I deactivate conda:
prokophapala#ProkopDesktop:~$ conda activate
(base) prokophapala#ProkopDesktop:~$ python --version
Python 3.9.12
(base) prokophapala#ProkopDesktop:~$ conda deactivate
prokophapala#ProkopDesktop:~$ python --version
Python 3.9.12
prokophapala#ProkopDesktop:~$ python3
Python 3.9.12 (main, Apr 5 2022, 06:56:58)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'numpy'
>>>
Activating a conda environment means that the location of the Python interpreter and the C-libraries (numpy) are temporarily added to the system path. After deactivation the old system path is restored.
Obviously during miniconda installation you enabled the option to "Add Python to the system path" which is not the default option and which is not recommended, since you can't access your previous Python any more.
So the solution is to check your system path, remove all miniconda Python references (except for the path to condabin) and add the path to your previous Python again. Note that you can have both interpreters in parallel on your system, but you always have to activate a conda environment before you can use it.
I just started having some problems with python, and would like to fix this the proper way, as a last resort, reinstalling if I have to.
Before Python 3, I had Python 2.7 installed. I then installed Python 3.7 along side it. I don't remember, if the path environment was automatically set, or if i manually set it.
My system variables path contains :
C:\Python27\;C:\Python27\Scripts;
So I believe this was set automatically.
My user variables path however contains :
C:\Python37\;C:\Python37\Scripts;
Would the python installer use the user environment? I'm not sure, so I don't know if I set that myself.
However, the user variables path also contains :
%PYTHON_DIR%\Python37\Scripts\;%PYTHON_DIR%\Python37\;%PYTHON_DIR%\Python36\Scripts\;%PYTHON_DIR%\Python36\
Again, I don't know if I set this myself, and I have no recollection of setting this in my user variables :
PYTHON_DIR = C:\Users\pcuser\AppData\Local\Programs\Python
...but it's there, and I have two folders in that path.
I also have this in my user variables path :
PYTHON = os.path.expanduser(os.getenv('PYTHON', 'C:\\Python37\\python.exe'))
I know I created a python environment. I just have to look for it, as I don't remember where to find it right now.
Here is the problem I am having.
I also am using Python in MSYS, and get this error from Python in C:\msys64\usr\bin :
Could not find platform independent libraries <prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
Current thread 0x0000000800018040 (most recent call first):
0 [main] python 1489 cygwin_exception::open_stackdumpfile: Dumping stack t
race to python.exe.stackdump
I set PYTHONHOME to C:\msys64\usr\bin. That doesn't solve the problem.
I also removed PYTHON_DIR to see if there was a conflict there, but that didn't solve the problem.
Rather, I got another error :
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
Current thread 0x0000000800018040 (most recent call first):
0 [main] python 143 cygwin_exception::open_stackdumpfile: Dumping stack tr
ace to python.exe.stackdump
So it seems to me my Python environment is messed up, and I want to learn how to set it up correctly, hopefully without having to start over.
How can I get rid of these errors, and get a proper python environment?
Personally, I use miniconda.
Miniconda is the small version of anaconda which is an excellent environment manager. Miniconda does not include a gui and I feel it is nicer to work with.
To create an environment with
conda create -n my-test-env python=3.9
You can activate it using
conda activate my-test-env
You can install other packages using
conda install numpy.
However, not all python packages are available in conda. You can any pip packages by installing pip
conda install pip
pip install numpy
Setting PYTHONHOME to a value like C:\msys64\usr\bin is definitely wrong; it should be something like C:\Python37\Lib if that's where Python installed its libraries. But try simply unsetting it.
After a while of troubleshooting, I was able to discover where the problem was.
Some files in C:\msys64\usr\lib\python3.8 somehow got deleted, or python 3.8 was installed, but not properly. So I did a reinstall, and python stopped complaining about missing encodings and modules.
Running a test on all python installations
MINGW64 ~
# python
Python 3.8.2 (default, Feb 27 2020, 05:27:33) [GCC 9.2.0 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
# python setup_build.py install
running install
running build
running build_ext
skipping 'geotools/geotools.c' Cython extension (up-to-date)
running install_lib
copying build/lib.mingw-3.8/geotools-cpython-38.dll -> C:/msys64/mingw64/lib/python3.8/site-packages
running install_egg_info
Writing C:/msys64/mingw64/lib/python3.8/site-packages/geotools-0.1.0-py3.8.egg-info
MINGW32 ~
# python
Python 3.8.2 (default, Feb 27 2020, 06:39:26) [GCC 9.2.0 32 bit] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
# python setup_build.py install
running install
running build
running build_ext
dllwrap: WARNING: dllwrap is deprecated, use gcc -shared or ld -shared instead
skipping 'geotools/geotools.c' Cython extension (up-to-date)
running install_lib
running install_egg_info
Removing C:/msys64/mingw32/lib/python3.8/site-packages/geotools-0.1.0-py3.8.egg-info
Writing C:/msys64/mingw32/lib/python3.8/site-packages/geotools-0.1.0-py3.8.egg-info
C:\WINDOWS\system32>py -3.7 -m pip list
Package Version
----------------------------- ---------
...
C:\WINDOWS\system32>py -2.7 -m pip list
DEPRECATION: Python 2.7 reached the end of its life on January 1st, 2020. Please
upgrade your Python as Python 2.7 is no longer maintained. pip 21.0 will drop s
upport for Python 2.7 in January 2021. More details about Python 2 support in pi
p can be found at https://pip.pypa.io/en/latest/development/release-process/#pyt
hon-2-support pip 21.0 will remove support for this functionality.
Package Version
----------------------------- ----------
...
C:\WINDOWS\system32>python
Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:25:58) [MSC v.1500 64 bit (AM
D64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\WINDOWS\\SYSTEM32\\python27.zip', 'C:\\Python27\\DLLs', 'C:\\Python27\
\lib', 'C:\\Python27\\lib\\plat-win', 'C:\\Python27\\lib\\lib-tk', 'C:\\Python27
', 'C:\\Users\\pcUser\\AppData\\Roaming\\Python\\Python27\\site-packages', 'C:\\Py
thon27\\lib\\site-packages', 'C:\\Python27\\lib\\site-packages\\pybind11-2.6.2-p
y2.7.egg']
>>>
C:\WINDOWS\system32>py -3
Python 3.7.7 (tags/v3.7.7:d7c567b08f, Mar 10 2020, 10:41:24) [MSC v.1900 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'C:\\Users\\pcUser\\AppData\\Local\\Programs\\Python\\Python37\\python37.zip'
, 'C:\\Users\\pcUser\\AppData\\Local\\Programs\\Python\\Python37\\DLLs', 'C:\\User
s\\pcUser\\AppData\\Local\\Programs\\Python\\Python37\\lib', 'C:\\Users\\pcUser\\App
Data\\Local\\Programs\\Python\\Python37', 'C:\\Users\\pcUser\\AppData\\Roaming\\Py
thon\\Python37\\site-packages', 'C:\\Users\\pcUser\\AppData\\Local\\Programs\\Pyth
on\\Python37\\lib\\site-packages']
>>>
C:\WINDOWS\system32>py -3.6 -m pip list
Package Version
--------------- --------
...
My python environment is good. All working nicely. :)
What I learned...
Using PYTHONHOME and PYTHONPATH is not neccesary, as was suggested by many... although equally suggessted by many.
From my experience - speaking fron a novice perspective - I would not recommend using them.
Maybe they work for others, but I got errors regardless of how I set it up - whether
C:\Python37 or
C:\Python37\lib or
C:\Users\pcUser\AppData\Local\Programs\Python\Python37 or
C:\msys64\usr\lib\python3.8;C:\msys64\usr\lib\python3.8\site-packages;C:\msys64\usr\lib\python3.8\lib-dynload;C:\msys64\usr\lib\python3.8\distutils
They all return a heap of errors on one installment or other.
So it does not work for me. However, probably works for others.
I am happy though that after probably more than 60 hours, my python environment is back in working order. :)
I am using miniconda to create several environments, all of which with Python 3.7. I found that for each env, the installed packages go to .local path, which means for different envs of Python 3.7, they share the same collections of packages.
For example:
Python 3.7.7 (default, May 7 2020, 21:25:33) [GCC 7.3.0] :: Anaconda, Inc. on linux Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__file__ '/home/my_name/.local/lib/python3.7/site-packages/numpy/__init__.py'
I suppose the installed packages should be in miniconda's directory, not my local .local directory.
How are you installing the packages? Are you using ‘conda env create’ for each new environment? You may need to check that the ‘base’ conda environment is running on your terminal, maybe you are using the default python interpreter instead of miniconda.
Also, if you are don’t have a specific reason to use conda, and just want it to manage virtual environments and packages, I would suggest that you try ‘pipenv’ instead. I found it to be simpler than conda and isolates pretty well the virtual environments.
I have build my virtual env with this command:
virtualenv env --distribute --no-site-packages
And then I have installed several modules (django etc) into env with pip, the problem is that when I wanted to run the code on the second machine it would not work, here is what I have done:
visgean#rewitaqia:~/scripty/project_name$ source ./env/bin/activate
(env)visgean#rewitaqia:~/scripty/project_name$ python
Python 2.7.1+ (r271:86832, Sep 27 2012, 21:12:17)
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> django.__file__
'/home/visgean/scripty/project_name/env/lib/python2.7/site-packages/django/__init__.pyc'
but when I want to run it on the second machine:
(env)user#debian:~/project_name$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named django
>>>
I wild error appears! The first machine is ubuntu, the second one is ubuntu. There seems to be some broken links in /home/user/project_name/env/lib/python2.7 , is that the problem? and if so, how should I prevent it/repair it?
If you are just copying the virtualenv to the second machine you may encounter some issues. From the virtualenv site:
Normally environments are tied to a specific path. That means that you
cannot move an environment around or copy it to another computer. You
can fix up an environment to make it relocatable with the command:
$ virtualenv --relocatable ENV
This will make some of the files
created by setuptools or distribute use relative paths, and will
change all the scripts to use activate_this.py instead of using the
location of the Python interpreter to select the environment.
Note: you must run this after you've installed any packages into the
environment. If you make an environment relocatable, then install a
new package, you must run virtualenv --relocatable again.
I have just noticed that I did have a wrong version of python on the second machine - debian does not have python2.7, installing 2.7 and pip for is the solution