I exported a conda environment in this way:
conda env export > environment.yml´
Then commited and pulled the environment.yml file to the git repo.
From another computer I cloned the repo and then tried to create the conda environment:
conda env create -f environment.yml
First I got a warning:
Warning: you have pip-installed dependencies in your environment file,
but you do not list pip itself as one of your conda dependencies.
Conda may not use the correct pip to install your packages, and they
may end up in the wrong place. Please add an explicit pip dependency.
I'm adding one for you, but still nagging you
I don't know why conda export does not include pip in the environment definition.
Then I got errors like wrong/unavailable versions of packages:
es-core-news-sm==3.0.0 version not found
I just removed the version part and only left the name of the package and got it work with:
conda env update --prefix ./env --file environment.yml --prune
Here additional details:
I would like to know how can I avoid this behavior?
es-core-news-sm==3.0 does not exist on pypi, where only 3.1 and 2.3.1 are available, hence your error message.
This is of course something very specific to the environment that you have and the packages that you have installed. In your specific case, just removing the version can be a fix, but no guarantee that this will work in all cases.
As for the cause, I can only guess, but what I expect happened in your case is:
You installed es-core-news-sm==3.0 to your environment
The developers of that package created a newer version and decided to delete the old version
Exporting the environment does correctly state that it contains es-core-news-sm==3.0
Creating an environment from the .yaml from step 3 fails, because the packe is not available any longer (see 2.)
An alternative (depending on your usecase) coul;d be to use conda-pack, which can create a packed version of your environment that you can then unpack. This only works though if the OS on the source and target machine are the same
I would think it's obvious that it should uninstall all packages when removing an environment, since how would they be accessed otherwise, but I haven't seen documentation saying so, so I'm checking here if all packages need to be removed first.
Let's be more specific and remove the env foo located at anaconda3/envs/foo with
conda env remove -n foo
This usually deletes everything under anaconda3/envs/foo.
PyPI packages may stick around. If you previously used pip install in the environment, it can occasionally leave some residual things behind. If that's the case, you'll need to delete the anaconda3/envs/foo folder manually after conda env remove. Or you could try to pip uninstall any PyPI packages first1, to get a clean conda env remove result.
Conda also caches all packages, independent of whether or not they are currently in use. This would be under anaconda3/pkgs (usually). To additionally delete the packages no longer in use, one can use
conda clean -tp # delete tarballs and unused packages
1: There is a command to programmatically remove all PyPI-installed packages from Conda environments in this answer.
The conda environment will be deleted. Sometimes some packages stay behind, although they are not bound to any environment. You can delete these under
<your anaconda folder> -> envs -> <the env you deleted>.
I've had to install a package with pip in a conda environment to get it to work for my application (link).
The package works fine. However, every time I modify the virtual environment in any way, conda tries to install the "missing" package - which would effectively result in downgrading it.
Question: is there a way to mark the pip package as 'manually installed' in the conda venv (e.g. in the same way apt-mark would handle it)? The intention is to get miniconda to leave it alone while still handling the remaining dependencies for the desired additional package.
The pip installed package indeed shows up when typing conda list, with Channel "pypi".
Can give any additional information if needed.
Thanks in advance for any help.
I have installed too many packages in my root environment in Anaconda. How can I reset Anaconda to its initial state without manually removing all packages on an individual basis?
You can revert fully to initial state with conda install --revision 0
If you want to do a partial rollback, you can try conda list --revisions and then conda install --revision xxx
Be careful using the answer above by #Paul-Antoine (answered Feb 8 at 15:43).
I strongly recommend using the command conda list --revisions first and outputting to a text file conda list --revisions > my_conda_history.txt and inspecting the results.
Look at your original ('rev 0') and early conda environment revisions ('rev 1, 2, 3, etc.) contained.
Roll back to the earlier revision before YOU installed a lot of "non-mainstream" or complex Python packages like Folio or Plotly. Packages like pandas, matplotlib, numpy, jupyter (classic) notebook, jupyterlab, spyder are considered mainstream because they are well-maintained core packages that ship pre-installed with most Python distributions.
For me revision 5 dated 2018-12-20 is about where I started installing some complex packages that gave me trouble (especially plotly, basemap, geos, and folium), because they were not stable, or were changing constantly, and they uninstalled current packages and re-installed earlier-version packages needed by my mainstream data science packages.
Roll back to your earlier state with only the mainstream packages, and then do a conda update --all to bring this former (but rolled back) environment current to today.
I found some additional answers elsewhere (referenced below) that state how to "roll back" the environment without blowing away conda itself or your other conda virtual environments that were created either with conda or Anaconda Navigator.
An option to reset environments has been added `In case anyone else find this thread, the issue that NumesSanguis points out above is resolved in conda versions from 4.3.33 and later. See Issue #6316.
But it's extremely important that you check your conda version before trying conda install --rev 1. Otherwise, you're going to lose all environments when you have to uninstall/reinstall conda.`
See also: enter link description here which says
See https://github.com/conda/conda/issues/1032
This has been implemented as conda list --revisions and conda install --rev REV_NUM.
EDIT: be careful though if you execute conda install --rev 0 as this
will remove your root environment and the conda command. Maybe conda
install --rev 1 would produce the desired behavior (restore root
environment to its state after first installation).
EDIT 2018-03-07: Use the --revision argument instead of --rev
I tried the conda search --outdated, there are lots of outdated packages, for example the scipy is 0.17.1 but the latest is 0.18.0. However, when I do the conda update --all. It will not update any packages.
update 1
conda update --all --alt-hint
Fetching package metadata .......
Solving package specifications: ..........
# All requested packages already installed.
# packages in environment at /home/user/opt/anaconda2:
#
update 2
I can update those packages separately. I can do conda update scipy. But why I cannot update all of them in one go?
TL;DR: dependency conflicts: Updating one requires (by it's requirements) to downgrade another
You are right:
conda update --all
is actually the way to go1. Conda always tries to upgrade the packages to the newest version in the series (say Python 2.x or 3.x).
Dependency conflicts
But it is possible that there are dependency conflicts (which prevent a further upgrade). Conda usually warns very explicitly if they occur.
e.g. X requires Y <5.0, so Y will never be >= 5.0
That's why you 'cannot' upgrade them all.
Resolving
Update 1: since a while, mamba has proven to be an extremely powerful drop-in replacement for conda in terms of dependency resolution and (IMH experience) finds solutions to problems where conda fails. A way to invoke it without installing mamba is via the --solver=libmamba flag (requires conda-libmamba-solver), as pointed out by matteo in the comments.
To add: maybe it could work but a newer version of X working with Y > 5.0 is not available in conda. It is possible to install with pip, since more packages are available in pip. But be aware that pip also installs packages if dependency conflicts exist and that it usually breaks your conda environment in the sense that you cannot reliably install with conda anymore. If you do that, do it as a last resort and after all packages have been installed with conda. It's rather a hack.
A safe way you can try is to add conda-forge as a channel when upgrading (add -c conda-forge as a flag) or any other channel you find that contains your package if you really need this new version. This way conda does also search in this places for available packages.
Considering your update: You can upgrade them each separately, but doing so will not only include an upgrade but also a downgrade of another package as well. Say, to add to the example above:
X > 2.0 requires Y < 5.0, X < 2.0 requires Y > 5.0
So upgrading Y > 5.0 implies downgrading X to < 2.0 and vice versa.
(this is a pedagogical example, of course, but it's the same in reality, usually just with more complicated dependencies and sub-dependencies)
So you still cannot upgrade them all by doing the upgrades separately; the dependencies are just not satisfiable so earlier or later, an upgrade will downgrade an already upgraded package again. Or break the compatibility of the packages (which you usually don't want!), which is only possible by explicitly invoking an ignore-dependencies and force-command. But that is only to hack your way around issues, definitely not the normal-user case!
1 If you actually want to update the packages of your installation, which you usually don't. The command run in the base environment will update the packages in this, but usually you should work with virtual environments (conda create -n myenv and then conda activate myenv). Executing conda update --all inside such an environment will update the packages inside this environment. However, since the base environment is also an environment, the answer applies to both cases in the same way.
To answer more precisely to the question:
conda (which is conda for miniconda as for Anaconda) updates all but ONLY within a specific version of a package -> major and minor. That's the paradigm.
In the documentation you will find "NOTE: Conda updates to the highest version in its series, so Python 2.7 updates to the highest available in the 2.x series and 3.6 updates to the highest available in the 3.x series."
doc
If Wang does not gives a reproducible example, one can only assist.
e.g. is it really the virtual environment he wants to update or could Wang get what he/she wants with
conda update -n ENVIRONMENT --all
*PLEASE read the docs before executing "update --all"!
This does not lead to an update of all packages by nature. Because conda tries to resolve the relationship of dependencies between all packages in your environment, this can lead to DOWNGRADED packages without warnings.
If you only want to update almost all, you can create a pin file
echo "conda ==4.0.0" >> ~/miniconda3/envs/py35/conda-meta/pinned
echo "numpy 1.7.*" >> ~/miniconda3/envs/py35/conda-meta/pinned
before running the update. conda issues not pinned
If later on you want to ignore the file in your env for an update, you can do:
conda update --all --no-pin
You should not do update --all. If you need it nevertheless you are saver to test this in a cloned environment.
First step should always be to backup your current specification:
conda list -n py35 --explicit
(but even so there is not always a link to the source available - like for jupyterlab extensions)
Next you can clone and update:
conda create -n py356 --clone py35
conda activate py356
conda config --set pip_interop_enabled True # for conda>=4.6
conda update --all
conda config
update:
Currently I would use mamba (or micromamba) as conda pkg-manager replacement
update:
Because the idea of conda is nice but it is not working out very well for complex environments I personally prefer the combination of nix-shell (or lorri) and poetry [as superior pip/conda .-)] (intro poetry2nix).
Alternatively you can use nix and mach-nix (where you only need you requirements file. It resolves and builds environments best.
On Linux / macOS you could use nix like
nix-env -iA nixpkgs.python37
to enter an environment that has e.g. in this case Python3.7 (for sure you can change the version)
or as a very good Python (advanced) environment you can use mach-nix (with nix) like
mach-nix env ./env -r requirements.txt
(which even supports conda [but currently in beta])
or via api like
nix-shell -p nixFlakes --run "nix run github:davhau/mach-nix#with.ipython.pandas.seaborn.bokeh.scikit-learn "
Finally if you really need to work with packages that are not compatible due to its dependencies, it is possible with technologies like NixOS/nix-pkgs.
Imagine the dependency graph of packages, when the number of packages grows large, the chance of encountering a conflict when upgrading/adding packages is much higher. To avoid this, simply create a new environment in Anaconda.
Be frugal, install only what you need. For me, I installed the following packages in my new environment:
pandas
scikit-learn
matplotlib
notebook
keras
And I have 84 packages in total.
I agree with Mayou36.
For example, I was doing the mistake to install new packages in the base environment using conda for some packages and pip for some other packages.
Why this is bad?
1.None of this is going to help with updating packages that have been > installed >from PyPI via pip, or any packages installed using python
setup.py install. conda list will give you some hints about the
pip-based Python packages you have in an environment, but it won't do
anything special to update them.
And I had all my projects in the same one environment! And I used update all -which is bad and did not update all-.
So, the best thing to do is to create a new environment for each project. Why?
2. A Conda environment is a directory that contains a specific collection of Conda packages that you have installed. For example, you
may be working on a research project that requires NumPy 1.18 and its
dependencies, while another environment associated with an finished
project has NumPy 1.12 (perhaps because version 1.12 was the most
current version of NumPy at the time the project finished). If you
change one environment, your other environments are not affected. You
can easily activate or deactivate environments, which is how you
switch between them.
So, to wrap it up:
Create a new environment for each project
Be aware for the differences in conda and pip
3.Only include the packages that you will actually need and update them properly only if necessary.
if working in MS windows, you can use Anaconda navigator. click on the environment, in the drop-down box, it's "installed" by default. You can select "updatable" and start from there
To update all possible packages I used conda update --update-all
It works!
I solved this problem with conda and pip.
Firstly, I run:
conda uninstall qt and conda uninstall matplotlib and conda uninstall PyQt5
After that, I opened the cmd and run this code that
pip uninstall qt , pip uninstall matplotlib , pip uninstall PyQt5
Lastly, You should install matplotlib in pip by this code that pip install matplotlib