Why I cannot update conda from a conda environment, but I can use it?
An example
I can update conda from root
[ravas#localhost ~]$ source activate
(base) [ravas#localhost ~]$ conda update conda
Solving environment: done
# All requested packages already installed.
I cannot update it from p36:
(base) [ravas#localhost ~]$ source activate p36
(p36) [ravas#localhost ~]$ conda update conda
PackageNotInstalledError: Package is not installed in prefix.
prefix: /home/ravas/miniconda3/envs/p36
package name: conda
This seems to occurs as conda is not installed in p36
(base) [ravas#localhost ~]$ conda list | grep conda
# packages in environment at /home/ravas/miniconda3:
anaconda-client 1.7.1 py37_0
anaconda-navigator 1.9.2 py37_0
conda 4.5.11 py37_0
conda-env 2.6.0 1
(p36) [ravas#localhost ~]$ conda list | grep conda
# packages in environment at /home/ravas/miniconda3/envs/p36:
anaconda 5.3.0 py36_0
anaconda-client 1.7.2 py36_0
anaconda-project 0.8.2 py36_0
pdfminer.six 20170720 py36_0 conda-forg
However, from p36 I can use conda
(p36) [ravas#localhost ~]$ conda update anaconda
Solving environment: done
# All requested packages already installed.
Why is that?
This is a consequence of how the shell (Bash, zsh, csh, fish, etc.) finds programs to execute. (The shell is the program that is running to process the commands you type in the terminal). The shell looks for executables in folders that are specified in the PATH environment variable. It searches these folders in the order that they're specified in that variable. If you look at the contents of the PATH with your environment activated, it should look something like
$ echo $PATH
/home/ravas/miniconda3/envs/p36/bin:/home/ravas/miniconda3/bin:...
When the shell tries to find the conda executable, it looks first in the environment directory; when it doesn't find it there, it looks in the base directory, where it does find it!
conda is not installed in the new environment. But you can get a conda in that derived environment like this:
activate the base environment
activate your other environment
run a conda install conda
Now you have a conda in that other environment, and work with that environment as usually.
Related
I have miniconda3 installed and since I would like to have an environment with python version 3.3.0, I create it via
conda create -n "myenv" python=3.3.0
However when I activate the environment via
conda activate myenv
python has version 2.7.15 and path
/usr/bin/python
and ipython has python version 3.6.8 and path
/home/myname/.local/bin/ipython
I can access the correct python with python3 which is at
/home/myname/miniconda3/envs/myenv/bin/python3
however, ipython3 has python version 3.6.8 again.
conda install python=3.3.0
left the situation unchanged.
A solution would be to open IPython via
python3 -m IPython
however, while this works fine for python here I get the error message
/home/myname/miniconda3/envs/myenv/bin/python3: No module named IPython
Is it possible to access with the commands python and ipython both python version 3.3.0 in that specific environment, i.e. not by setting an alias in the .bashrc?
EDIT:
Turns out that this problem does not occur if you select version 3.3 instead of 3.3.0 together with #ilmarinen's answer
conda create -n "myenv" python=3.3 ipython
everything works fine and python as well as ipython result to version python 3.3.5.
You need to install ipython as well into your given environment
conda create -n "myenv" python=3.3.0 ipython
The conda environments are prepended to your PATH variable, so when you are trying to run the executable "ipython", Linux will not find "ipython" in your activated environment (since it doesn't exist there), but it will continue searching for it, and eventually find it wherever you have it installed.
To create an environment named py33 with python 3.3.0, using the channel conda-forge and a list of packages:
conda create -y --name py33 python==3.3.0
conda install -f -y -q --name py33 -c conda-forge --file requirements.txt
conda activate py33
...
conda deactivate
Alternatively you can use
conda env create -f environment.yml
for using an environment.yml file instead of requirements.txt:
name: py33
channels:
- conda-forge
dependencies:
- python==3.3.0
- ipython
Use this command to remove the environment:
conda env remove -n py33
I had similar issue. And I could't find many useful discussions.
The problem for me was I have alias pointing python to miniconda python hardcoded in my shell config file when I execute conda init zsh. Somehow the init process copies the alias and always reload that, thus overwrites the "correct" version.
After conda create -n py27 python=2.7 (my system default is 3.6), the version was correctly installed at miniconda3/envs/py27/bin/python. But the activated evironment python was not pointing to it, as indicated by which python,even if I deleted updated my shell config.
In the end it was solved by 'reverse' conda init (remove the generated conda function in .zshrc), remove alias, and re-init.
I guess other shell is using the same mechanism.
Conda says the package is already installed and will not install it again, but when I list the packages in the environment, there are no packages installed.
When I try to import the package in a notebook file, it fails.
Running a terminal shell launched from JupyterLab:
Use pip to uninstall bashplotlib - that works
Use Conda to activate an environment -- That works
Use Conda to install bashplotlib -- It fails because it's already supposedly installed
Use Conda to print the packages installed in the Conda environment -- There are none listed
PS C:\Users\nicomp> pip uninstall bashplotlib
Uninstalling bashplotlib-0.6.5:
Would remove:
c:\users\nicomp\anaconda3\lib\site-packages\bashplotlib-0.6.5-py2.7.egg-info
c:\users\nicomp\anaconda3\lib\site-packages\bashplotlib\*
c:\users\nicomp\anaconda3\scripts\hist-script.py
c:\users\nicomp\anaconda3\scripts\scatter-script.py
c:\users\nicomp\anaconda3\scripts\scatter.exe
Proceed (Y/n)? y
Successfully uninstalled bashplotlib-0.6.5
PS C:\Users\nicomp> conda activate fooEnvironment
PS C:\Users\nicomp> conda info --envs
# conda environments:
#
base * C:\Users\nicomp\anaconda3
bashplotlibEnvironment C:\Users\nicomp\anaconda3\envs\bashplotlibEnvironment
condaTestEnvironment C:\Users\nicomp\anaconda3\envs\condaTestEnvironment
fooEnvironment C:\Users\nicomp\anaconda3\envs\fooEnvironment
jupyterlab-debugger C:\Users\nicomp\anaconda3\envs\jupyterlab-debugger
microservices C:\Users\nicomp\anaconda3\envs\microservices
ml C:\Users\nicomp\anaconda3\envs\ml
someEnvironment C:\Users\nicomp\anaconda3\envs\someEnvironment
zzz C:\Users\nicomp\anaconda3\envs\zzz
PS C:\Users\nicomp> conda install -c conda-forge bashplotlib
Collecting package metadata (current_repodata.json): done
Solving environment: done
# All requested packages already installed.
PS C:\Users\nicomp> conda list -n fooEnvironment
# packages in environment at C:\Users\nicomp\anaconda3\envs\fooEnvironment:
#
# Name Version Build Channel
PS C:\Users\nicomp>
Activation Failing
From the conda info --envs output, it indicates that the conda activate command is not working, since the output shows that base is still activated (that's what "*" indicates). That is, despite the efforts, the package is getting installed in base.
Specifying Target Environment
I can't answer why the environment activation is broken (this can be specific to PowerShell or the Jupyter terminal - try searching), but I can at least recommend a more robust installation command. Rather than relying on environment activation, most Conda commands support specification of the target environment using the --name,-n or --prefix,-p flags. In this case,
conda install -n fooEnvironment -c conda-forge bashplotlib
would work no matter what environment happens to be activated.
I'd encourage this as a good habit to adopt because it makes the command less context-sensitive.
I wanted to create a conda environment to work on a Django Web App.
I checked if the environment had existed before:
conda activate django_movie_app
Could not find conda environment: django_movie_app
You can list all discoverable environments with `conda info --envs`.
Then I created my environment using:
conda create --name django_movie_app
Collecting package metadata (current_repodata.json): done
Solving environment: done
However after I activated the environment using
`conda activate django_movie_app`
I checked pip freeze and all system packages were installed
pip freeze
alabaster==0.7.12
anaconda-client==1.7.2
anaconda-navigator==1.9.12
anaconda-project==0.8.3
argh==0.26.2
asgiref==3.2.4
asn1crypto==1.3.0
astroid==2.3.3
astropy==4.0.1.post1
atomicwrites==1.4.0
attrs==19.3.0
autopep8==1.5
Babel==2.8.0
backcall==0.1.0
backports.functools-lru-cache==1.6.1
backports.shutil-get-terminal-size==1.0.0
backports.tempfile==1.0
backports.weakref==1.0.post1
bcrypt==3.1.7
beautifulsoup4==4.9.0
bitarray==1.2.1
bkcharts==0.2
bleach==3.1.4
bokeh==1.4.0
boto==2.49.0
Bottleneck==1.3.2 etc
Running conda info returned the environment was active:
conda info
active environment : django_movie_app
I have tried reinstalling the environments after deleting them from the explorer (They were not available afterwards --> See above) and I still had the same problem afterwards.
I have created normal environments before where this was not a problem. However, now conda keeps installing all packages and some older versions cannot be uninstalled using pip uninstall.
With the commands you listed above, you haven't actually installed anything to the django_movie_app environment yet, so when you call pip, your shell is finding some other version of pip that happens to exist on your PATH -- not one from the django_movie_app environment. (It looks like your conda base environment is still on your PATH somewhere. That's not necessarily a problem, as long as django_movie_app/bin.)
Does everything work as expected if you try the following commands?
conda create -n django_movie_app
conda activate django_movie_app
conda install python=3.7
pip freeze
BTW, the conda command to list your current environment's installed packages is:
conda list
...which gives a little more info than pip freeze.
conda create --name py37 python=3.7
conda activate py37
Check the Conda Cheat sheet for more understanding and to see multiple commands with their description.
I have installed python 3.5 with the following commando:
conda create -n py35 python=3.5 anaconda
I also have a base Anaconda python27 installed. When I wish to update it I just write:
conda update conda
But how do I update my pyhon35?
I have tried this:
activate py35
[py35] C:\Users\trofl>cd C:\Users\trofl\Anaconda2\envs\py35
[py35] C:\Users\trofl\Anaconda2\envs\py35>conda install conda
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ....
Solving package specifications: .........
Error: 'conda' can only be installed into the root environment
It looks like you are trying to install when you have conda-env and conda-build in your current environment. You have to remove these first to update conda.
source activate my-env
conda remove conda-build
conda remove conda-env
conda update anaconda
I created a new python3 environment to install python 3; due to the incompatibility between conda and Windows PowerShell, I installed python 3 in both of the root and python3 environment by accident. Is it possible to revert to python 2 in the root environment?
C:\Users\Nick>conda info --env
# conda environments:
#
python3 C:\application\anaconda\envs\python3
root * C:\application\anaconda
C:\Users\Nick>python -V
Python 3.3.5 :: Continuum Analytics, Inc.
conda install python=2 should do the trick. Definitely check and make sure that all packages downgraded successfully by inspecting the output of conda list for versions that contain the py3 string. For any packages that contain py3 in the version string, you should probably just uninstall/reinstall them.
(Hypothetical) Example:
The third column in conda list is the python version. If you see:
anaconda-client 1.1.2 py35_0 defaults
then you should
conda remove anaconda-client
followed by
conda install anaconda-client so that it installs the python 2 version.
Then conda list should show the anaconda-client line like this:
anaconda-client 1.1.2 py27_0 defaults.