I am trying to update the package flopy, within a virtual environment called flopyenv using the Anaconda Prompt command line. First, I activate the virtual environment using conda activate flopyenv. Then to update flopy, I've tried conda update flopy. I get the following error:
PackageNotInstalledError: Package is not installed in prefix.
prefix: C:\Users\person\Anaconda3\envs\flopyenv
package name: flopy
which makes sense since the flopy directory was installed in a different directory (C:\Users\person\Anaconda3\envs\flopyenv\lib\site-packages\flopy). Also, I have checked using conda list and flopy is listed in the environment. How do I point conda update to the proper directory to update flopy within the virtual environment?
Edit: Per merv's comment I've included the output below.
(flopyenv) C:\Users\person>conda list -n flopyenv flopy
# packages in environment at C:\Users\person\Anaconda3\envs\flopyenv:
#
# Name Version Build Channel
flopy 3.3.1 pypi_0 pypi
Looks like I used pip to install flopy not conda which I guess is why the directories weren't lining up when I tried updating using conda. I was able to successfully update the flopy package using pip.
Seems like OP figured it out, but it may be worth mentioning that in addition to using pip to update, it might also work to enable the pip_interop_enabled configuration option. I would only do this on a per-environment basis:
conda activate flopyenv
conda config --env --set pip_interop_enabled true
conda update flopy
However, this is still (as of Conda v 4.9) considered an experimental feature, AFAIK.
Related
I want to export an environment AND its packages, using conda 4.10.
Reading the conda docs, it suggests exporting environments using conda env export > environment.yml. However, I am not sure if it is my problem (and if so, what the solution is), but there is no package information.
name: guest
channels:
- defaults
prefix: C:\Anaconda3\envs\guest
After some googling, I learnt to export packages using conda list --export > requirements.txt. This time, there is no environment information.
# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: win-64
ca-certificates=2021.5.30=h5b45459_0
certifi=2021.5.30=py38haa244fe_0
...
How do I export both into one file and use it? Or should I just export two files, create an environment first, and install the packages?
On a side note, how do I make my packages match requirements.txt, that is, to remove extra packages, install missing ones, and update/ downgrade to the specific version? Is there a command for this, or should I delete the whole environment and start from scratch?
I attempted to downgrade my conda version. With conda at version 4.6.2, I ran conda install conda=4.5.12. I then went to run other conda commands, but was met with the following error:
CondaUpgradeError: This environment has previously been operated on by a conda version that's newer
than the conda currently being used. A newer version of conda is required.
target environment location: /home/selah/anaconda3
current conda version: 4.5.12
minimum conda version: 4.6
I am now stuck and unable to successfully run any conda commands. How can I get conda back in working order again?
The conda documentation explicitly mentions this issue in their "Troubleshooting" documentation
Conda upgrade error
Cause
Downgrading conda from 4.6.1 to 4.5.x and then trying to conda install conda or conda upgrade conda will produce a solving and upgrade error similar to the following:
Solving environment: failed
CondaUpgradeError: This environment has previously been operated on by a
conda version that's newer than the conda currently being used. A newer
version of conda is required.
target environment location: /opt/conda
current conda version: 4.5.9
minimum conda version: 4.6
Solution
Change the .condarc file. Set the parameter by editing the .condarc file directly: allow_conda_downgrades: true in conda version 4.5.12. This will then let you upgrade. If you have something older than 4.5.12, install conda 4.6.1 again from the package cache.
EXAMPLE: If my conda info says package cache : /opt/conda/pkgs and my Python version is 3.7, then on the command line, type conda install /opt/conda/pkgs/conda-4.6.1-py37_0.tar.bz2 to resolve the issue.
This should already provide enough information to at least try to recover from that problem. I decided to add a few additional informations and to rephrase it in my own words:
Solution if you downgraded to 4.5.12
Since you installed 4.5.12 you should be able to simply modify the .condarc file and include (or change) allow_conda_downgrades: true.
The documentation "Using the .condarc conda configuration file" provides the possible locations for the .condarc file:
The .condarc file is not included by default, but it is automatically created in your home directory the first time you run the conda config command.
A .condarc file may also be located in the root environment, in which case it overrides any in the home directory.
Then update to 4.6 again (or whatever version you had previously):
conda install conda=4.6.2
Then change the setting in the .condarc file back to false:
allow_conda_downgrades: false
The last step is optional but I think the default is false to protect users from metadata-corruption by old conda versions. So I would change it back after recovering from the exception.
Solution if you downgraded to 4.5.x where x is smaller than 12 (or the above did not work)
If that doesn't work or you had downgraded to an earlier version of conda 4.5.x then you have to use the other approach. Run:
conda info
Search for the line that starts with package cache :. Navigate to that directory and look for conda....tar.gz.bz2 files. Select the one that you had previously installed and then run:
conda install PATH # <- replace the PATH with the actual path to the selected conda file
Note that you can also download the file from the anaconda channel directly and then provide the path to this downloaded file.
Last Resort (if you're desperate and nothing worked)
In case that did not work you could try brute-force approaches. Although be warned that they could do even more damage to your conda setup - treat them as last resort (e.g. when you consider uninstalling and reinstalling conda/anaconda).
For example you could also try to manually "install" it over the existing installation (again: this may not work and maybe you cannot undo this step again!):
Use the conda "tar.gz.bz2" file found by the previous step (or if you don't have it download it from the anaconda channel: https://anaconda.org/anaconda/conda/files)
Extract it into your root environment replacing existing files.
Hope!
Hope!
Test if it worked
I really struggled with this issue.
All the solutions here did not work for me. This is what works for me:
Find the /conda-meta/history file in the root. (Multile Locations)
Delete or rename it,
Then conda update conda.
To help local this folder on mac you can use: mdfind kind:folder "conda-meta"
In Windows, I used Isaacsh's solution:
https://github.com/conda/conda/issues/1757
to create the .condarc file inside my c:\users\<username> folder. I then added
allow_conda_downgrades: true using Notebook
At the Anaconda Prompt, I entered conda install conda=4.6 and it installed version 4.6.3
In Windows, if you have Anaconda Navigator installed, open it and update the conda version there from the GUI.
To be on the safe side, I was advised to keep to
$ conda update anaconda
However, some tutorials on internet recommends
$ conda update conda
$ conda update --all
The above two commands lead to the installation of custom packages. Will it cause anaconda to be unstable? Is it safer to simply keep to conda update anaconda?
Custom packages refer to packages with names that contain the word "custom". They do not belong to the standard anaconda package.
conda packages with version name of 'custom'
I am using Anaconda Python version 3.
Open "Command or Conda Prompt" and run:
conda update conda
conda update anaconda
It's a good idea to run both commands twice (one after the other) to be sure that all the basic files are updated.
This should put you back on the latest 'releases', which contains packages that are selected by the people at Continuum to work well together.
If you want the last version of each package run (this can lead to an unstable environment):
conda update --all
If you are implementing some projects and they depend on the previous version of some packages then running $ conda update --all will be disastrous. It may break some of the code from your project.
Running $ conda update anaconda will be a safe option because along with anaconda it will update all of the required dependencies to the required version.
The conda docs at http://conda.pydata.org/docs/using/envs.html explain how to share environments with other people.
However, the docs tell us this is not cross platform:
NOTE: These explicit spec files are not usually cross platform, and
therefore have a comment at the top such as # platform: osx-64 showing the
platform where they were created. This platform is the one where this spec
file is known to work. On other platforms, the packages specified might not
be available or dependencies might be missing for some of the key packages
already in the spec.
NOTE: Conda does not check architecture or dependencies when installing
from an explicit specification file. To ensure the packages work correctly,
be sure that the file was created from a working environment and that it is
used on the same architecture, operating system and platform, such as linux-
64 or osx-64.
Is there a good method to share and recreate a conda environment in one platform (e.g. CentOS) in another platform (e.g. Windows)?
This answer is given with the assumption that you would like to make sure that
the same versions of the packages that you generally care about are on
different platforms and that you don't care about the exact same versions of
all packages in the entire dependency tree. If you are trying to install the
exact same version of all packages in your entire dependency tree that has a
high likelihood of failure since some conda packages have different
dependencies for osx/win/linux. For example, the recipe for
otrobopt
will install different packages on Win vs. osx/linux, so the environment list
would be different.
Recommendation: manually create an environment.yaml file and specify or pin
only the dependencies that you care about. Let the conda solver do the rest.
Probably worth noting is that conda-env (the tool that you use to manage conda
environments) explicitly recommends that you "Always create your
environment.yml file by hand."
Then you would just do conda env create --file environment.yml
Have a look at the readme for
conda-env.
They can be quite simple:
name: basic_analysis
dependencies:
- numpy
- pandas
Or more complex where you pin dependencies and specify anaconda.org channels to
install from:
name: stats-web
channels:
- javascript
dependencies:
- python=3.4 # or 2.7 if you are feeling nostalgic
- bokeh=0.9.2
- numpy=1.9
- nodejs=0.10
- flask
- pip:
- Flask-Testing
In either case, you can create an environment with conda env create --file environment.yaml.
NOTE: You may need to use .* as a version suffix if you're using an older version of conda.
Whilst it is possible to create your environment.yml file by hand, you can ensure that your environment works across platforms by using the conda env export --from-history flag.
This will only include packages that you’ve explicitly asked for, as opposed to including every package in your environment.
For example, if you create an environment and install a package conda install python=3.8 numpy, it will install numerous other dependencies as well as python and numpy.
If you then run conda env export > environment.yml, your environment.yml file will include all the additional dependencies conda automatically installed for you.
On the other hand, running conda env export --from-history will just create environment.yml with python=3.8 and numpy and thus will work across platforms.
Answer adapted from the docs.
For those interested in a solution to maintain a single environment file that can be used in Linux, macOS, and Windows, please check the conda-devenv tool at https://github.com/ESSS/conda-devenv.
conda-env export should be used used to export your complete environment to file named my_env.yml.
Check the working solution on getting only prefix on OS X instead of complete dependency including pip.
Step 1: deactivate from the environment if activated. else it will create yml file with only prefix.
Step 2: run below command to export
conda-env export -n my_env > my_env.yml
it will export every required dependency, channel and pip install in a yml file which is importable to share with others.
Step 3: run below command to import
conda-env create -n my_env -f= my_env.yml
it will create the exact environment as is on sharing fellow machine.
An aspect missing from the other answers is that the question asker mentions "spec files" and not "environment.yml" file. These are different.
Spec file
A spec file specifies the exact package URL's and is used to recreate identical environments (on the same platform).
It looks like this:
# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: osx-64
#EXPLICIT
https://repo.anaconda.com/pkgs/free/osx-64/mkl-11.3.3-0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/numpy-1.11.1-py35_0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/openssl-1.0.2h-1.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/pip-8.1.2-py35_0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/python-3.5.2-0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/readline-6.2-2.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/setuptools-25.1.6-py35_0.tar.bz2
It can be obtained with conda list --explicit from the conda environment of interest.
To create a new environment with it one would use the conda create command:
conda create --name <env_name> --file <spec file path>
environment.yml
The environment.yml file is described well in this answer.
It can be obtained with the following commands from the conda environment of interest:
conda env export to get all packages in the current environment
conda env export --from-history to only get the packages explicitly installed (i.e. not automatically added depenedencies)
This question is quite old and conda has developed in the meantime. Perhaps the original meaning of spec file was equal to environment.yml files, but for completeness I am adding this answer.
None of these solutions worked out for me, the problem the OP has raised is about platform dependent suffixes added in the dependency making it impossible to be used it in a cross-platform way.
Turns out the solution for this is to export the environment with an additional option called no-builds
Suppose you want to export your environment from MacOS to Debian.
1.) Invoke conda env export --no-builds > env_macos.yml
2.) Invoke cp env_macos.yml env_debian.yml
3.) Move env_debian.yml to your Debian host
4.) conda env create -f env_debian.yml
Soon after you do 4, again there may be same package resolving related issues for certain packages, just remove those entries alone and invoke 4 again. Things will work.
Reference
The conda docs at http://conda.pydata.org/docs/using/envs.html explain how to share environments with other people.
However, the docs tell us this is not cross platform:
NOTE: These explicit spec files are not usually cross platform, and
therefore have a comment at the top such as # platform: osx-64 showing the
platform where they were created. This platform is the one where this spec
file is known to work. On other platforms, the packages specified might not
be available or dependencies might be missing for some of the key packages
already in the spec.
NOTE: Conda does not check architecture or dependencies when installing
from an explicit specification file. To ensure the packages work correctly,
be sure that the file was created from a working environment and that it is
used on the same architecture, operating system and platform, such as linux-
64 or osx-64.
Is there a good method to share and recreate a conda environment in one platform (e.g. CentOS) in another platform (e.g. Windows)?
This answer is given with the assumption that you would like to make sure that
the same versions of the packages that you generally care about are on
different platforms and that you don't care about the exact same versions of
all packages in the entire dependency tree. If you are trying to install the
exact same version of all packages in your entire dependency tree that has a
high likelihood of failure since some conda packages have different
dependencies for osx/win/linux. For example, the recipe for
otrobopt
will install different packages on Win vs. osx/linux, so the environment list
would be different.
Recommendation: manually create an environment.yaml file and specify or pin
only the dependencies that you care about. Let the conda solver do the rest.
Probably worth noting is that conda-env (the tool that you use to manage conda
environments) explicitly recommends that you "Always create your
environment.yml file by hand."
Then you would just do conda env create --file environment.yml
Have a look at the readme for
conda-env.
They can be quite simple:
name: basic_analysis
dependencies:
- numpy
- pandas
Or more complex where you pin dependencies and specify anaconda.org channels to
install from:
name: stats-web
channels:
- javascript
dependencies:
- python=3.4 # or 2.7 if you are feeling nostalgic
- bokeh=0.9.2
- numpy=1.9
- nodejs=0.10
- flask
- pip:
- Flask-Testing
In either case, you can create an environment with conda env create --file environment.yaml.
NOTE: You may need to use .* as a version suffix if you're using an older version of conda.
Whilst it is possible to create your environment.yml file by hand, you can ensure that your environment works across platforms by using the conda env export --from-history flag.
This will only include packages that you’ve explicitly asked for, as opposed to including every package in your environment.
For example, if you create an environment and install a package conda install python=3.8 numpy, it will install numerous other dependencies as well as python and numpy.
If you then run conda env export > environment.yml, your environment.yml file will include all the additional dependencies conda automatically installed for you.
On the other hand, running conda env export --from-history will just create environment.yml with python=3.8 and numpy and thus will work across platforms.
Answer adapted from the docs.
For those interested in a solution to maintain a single environment file that can be used in Linux, macOS, and Windows, please check the conda-devenv tool at https://github.com/ESSS/conda-devenv.
conda-env export should be used used to export your complete environment to file named my_env.yml.
Check the working solution on getting only prefix on OS X instead of complete dependency including pip.
Step 1: deactivate from the environment if activated. else it will create yml file with only prefix.
Step 2: run below command to export
conda-env export -n my_env > my_env.yml
it will export every required dependency, channel and pip install in a yml file which is importable to share with others.
Step 3: run below command to import
conda-env create -n my_env -f= my_env.yml
it will create the exact environment as is on sharing fellow machine.
An aspect missing from the other answers is that the question asker mentions "spec files" and not "environment.yml" file. These are different.
Spec file
A spec file specifies the exact package URL's and is used to recreate identical environments (on the same platform).
It looks like this:
# This file may be used to create an environment using:
# $ conda create --name <env> --file <this file>
# platform: osx-64
#EXPLICIT
https://repo.anaconda.com/pkgs/free/osx-64/mkl-11.3.3-0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/numpy-1.11.1-py35_0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/openssl-1.0.2h-1.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/pip-8.1.2-py35_0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/python-3.5.2-0.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/readline-6.2-2.tar.bz2
https://repo.anaconda.com/pkgs/free/osx-64/setuptools-25.1.6-py35_0.tar.bz2
It can be obtained with conda list --explicit from the conda environment of interest.
To create a new environment with it one would use the conda create command:
conda create --name <env_name> --file <spec file path>
environment.yml
The environment.yml file is described well in this answer.
It can be obtained with the following commands from the conda environment of interest:
conda env export to get all packages in the current environment
conda env export --from-history to only get the packages explicitly installed (i.e. not automatically added depenedencies)
This question is quite old and conda has developed in the meantime. Perhaps the original meaning of spec file was equal to environment.yml files, but for completeness I am adding this answer.
None of these solutions worked out for me, the problem the OP has raised is about platform dependent suffixes added in the dependency making it impossible to be used it in a cross-platform way.
Turns out the solution for this is to export the environment with an additional option called no-builds
Suppose you want to export your environment from MacOS to Debian.
1.) Invoke conda env export --no-builds > env_macos.yml
2.) Invoke cp env_macos.yml env_debian.yml
3.) Move env_debian.yml to your Debian host
4.) conda env create -f env_debian.yml
Soon after you do 4, again there may be same package resolving related issues for certain packages, just remove those entries alone and invoke 4 again. Things will work.
Reference