How to delete unnamed conda environemt - anaconda

I am using Anaconda on macOS. Apart from the base environment, I created pip when I am installing libraries available only from that channel.
But I have one called 'anaconda3' which I can see in Navigator
and also see when checking envs in terminal:
% conda info --envs
# conda environments:
#
base * /Users/marek/opt/anaconda3
pip_env /Users/marek/opt/anaconda3/envs/pip_env
/opt/anaconda3
The thing is that it works strangely, it seems to be at the same location as base but does not work as base env. I can switch it and install different libraries etc. But it works strangely and I cannot update any apps (jupyter, spyder) in it so I want to delete but it is not possible as it has no name.
my goal is to remove that anconda3 (/opt/anaconda3 without any name in terminal) environment

It's perfectly fine that your pip_env environment is in the envs subfolder. This is the default location. You can delete in 3 ways:
conda env remove --name pip_env
or
conda remove --all --prefix "/Users/marek/opt/anaconda3/envs/pip_env"
or you simply delete the folder using your shell. Conda environments are self contained.

You can remove nameless environments using prefix:
conda env remove -p /opt/anaconda3

Related

How to create a conda environment file without local development packages?

I have a conda environment with packages installed via conda install. I also have two local development packages that were each installed with pip install -e .. Now, conda env export shows everything, including both local development packages. However, I don't want conda to include them when creating the same environment on other machines - I want to keep doing it via pip install -e ..
So how can I exclude both local packages when creating the environment.yml file? Do I need to manually remove them or is there a way to this from the command line?
While there are some alternative flags for conda env export that change output behavior (e.g., --from-history is most notable), there really isn't anything as specific as OP describes. Instead, manually remove the offending lines.
Note that YAMLs do support all pip install commands, so the editable installs can also be included. For example, https://stackoverflow.com/a/59864744/570918.
Consider Prioritizing the YAML Specification
In a software engineering setting, I would expect that users should not even be hitting development environments with conda install or pip install commands. Instead, the team should have a maunally-written, version-controlled YAML to begin with and all installations/changes to the environment are managed through editing the YAML file and using conda env update to propagate changes in the YAML to the environment.
That is, conda env export should not be necessary because the environment already has a well-defined means of creation.

deleting conda environment safely?

I'm new to anaconda and conda. I have created an identical environment in two different directories. Is it safe to just delete the env folder or the environment that I no longer need, or do I need to do something in the anaconda prompt to remove the environment thoroughly? I'm not sure if creating an environment in a local folder leaves a trace in the registry or somewhere else in the computer that needs to be removed too?
conda remove --name myenv --all
Another option is
conda env remove --name myenv
Effectively no difference from the accepted answer, but personally I prefer to use conda env commands when operating on whole envs, and reserve conda remove for managing individual packages.
The difference between these and deleting the folder manually is that Conda provides action hooks for when packages are removed, and so allows packages to execute pre-unlink and post-unlink scripts.

How to associate a conda enviroment with a project directory

I have been using miniconda for a while and have set up conda environments for each for each of my projects. What I can't figure out after looking through the documentation, is there a way to bond/associate my conda environment to my project folder for that conda environment? So that when I activate a specific conda environment it moves directly into the associated project directory. This virtualenvwrapper etc. can do for example. Is conda able to this?
As mentioned in Activating an environment, conda automatically executes "activation scripts" when an environment is activated. These scripts are typically provided by conda packages installed in the environment.
Just add a script of your own with a cd command. See here for details:
https://stackoverflow.com/a/43415167/11451509

do packages installed (without --name ) after conda environment activation affect outside?

I want to know after creating and activating a conda environment in terminal. Say venv:
conda create -n venv
source activate venv
Then the prompt will come with the enviroment name (venv).
would the packages installed (say conda install tensorflow without --name venv) after environment activation only effect inside the environment venv? Or would it affect outside venv?
I don't want to mess up my environments.
The point of using an environment in conda is to have a separate space where you can install packages and apply your configurations.
As long as you are inside an environment, all the packages you install will only be installed there. One way you can check this is by listing the packages you installed using: conda list
You will see that the packages you installed in the active environment are not installed in the other ones.
I hope this answers your question

Weird behavior of conda when creating empty environments

I create a conda environment without specifying any packages using the following command:
conda create --name test_env
I can then use all the packages in the root environment inside test_env (but they do not appear in the outputs of conda list and conda env export). This is already unexpected to me but the real problems begin when I then install something inside that environment, e.g.:
conda install pywavelets
Afterwards, pywavelets is usable but all the other packages which are no dependencies of pywavelets disappear inside the environment (e.g. pandas). I don't understand why that happens. Does anybody have an explanation for that?
More importantly, what does this mean for best practices for working with conda environments? Should I always create my environments specifying at least python (conda create --name test_env python)? However, then I have to install everything by hand in that environment which is quite cumbersome. So, my idea now is to specify anaconda for all environments I create:
conda create --name test_env anaconda
The disadvantage, however, is that the list of dependencies listed by conda list and conda env export gets unnecessarily long (e.g. even listing the Anaconda Navigator). Does anybody have a better solution for this?
The reason you can use all the packages from the root environment when you don't specify a Python version during environment creation is because you're actually using the root environment's Python executable! You can check with which python or python -c "import sys; print(sys.executable)". See also my other answer here.
When you install pywavelets, one of the dependencies is (probably) Python, so a new Python executable is installed into your environment. Therefore, when you run Python, it only picks up the packages that are installed in the test_env.
If you want all of the packages from another environment, you can create a file that lists all the packages and then use that file to create a new environment, as detailed in the Conda docs: https://conda.io/docs/user-guide/tasks/manage-environments.html#building-identical-conda-environments
To summarize
conda list --explicit > spec-file.txt
conda create --name myenv --file spec-file.txt
or to install into an existing environment
conda install --name myenv --file spec-file.txt
Since that's just a text file, you can edit and remove any packages that you don't want.

Resources