256

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?

Timur Shtatland
  • 12,024
  • 2
  • 30
  • 47
Wang
  • 7,250
  • 4
  • 35
  • 66
  • 5
    It may be because the latest scipy has a conflicting dependency. For instance, it may require NumPy 1.11, but you have a different package that requires NumPy 1.10. You can try `conda update --all --alt-hint` and see if it gives any output... Or just try `conda update scipy` and see what happens (perhaps with the `--alt-hint` flag) – darthbith Aug 16 '16 at 13:09
  • @darthbith please refer to update 1. No useful info. – Wang Aug 16 '16 at 14:04
  • 1
    `But why I cannot update all of them in one go?` Probably because you have at least one package that depends on an older version and thus nothing can be updated. – cel Aug 16 '16 at 16:42
  • Is it possible to find out which one depends on old packages? – Wang Aug 17 '16 at 05:39
  • After nearly a year and no other answer, I think it would be appropriate to accept this as the right answer, don't you think? Or does it not apply for your case somehow? – Mayou36 Mar 07 '18 at 09:51
  • 4
    I recommend running `conda update conda` before `conda update --all` – gizzmole Sep 10 '18 at 08:26
  • `conda: error: unrecognized arguments: --alt-hint` in conda 4.8.2 – BallpointBen Mar 09 '20 at 01:07
  • @gizzmole why you say it is better to run `conda update conda` before running `conda update --all`? – Redoman Dec 07 '22 at 07:07

7 Answers7

396

TL;DR: dependency conflicts: Updating one requires (by its 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.

danronmoon
  • 3,814
  • 5
  • 34
  • 56
Mayou36
  • 4,613
  • 2
  • 17
  • 20
  • 2
    If you are using conda don't break your environment when you overwrite with pip! If are are using an Data Science environment DON'T install pkgs isolated because you are more likely then with pip to break your env. – InLaw Sep 28 '19 at 06:54
  • 1
    I agree, using pip makes conda not work anymore reliably. I've added this into the answer explicitly. – Mayou36 Sep 30 '19 at 07:52
  • 1
    @Mayou36 What InLaw was actually saying was even more strict. pip *breaks* the conda env. That's good to know for someone just wanting to 'get it to run' and not bother with the package installation demons. – StarShine Feb 03 '21 at 13:13
  • @StarShine can you elaborate on this? It is true that after installing with pip, you should no longer install with conda, in this sense it _breaks_ it. But not in the sense that it is not usable anymore, pip installs can be made and code can be run. However, it's a completely "legal" procedure as pip packages can be included in the env.yaml and is mentioned [on the conda page](https://www.anaconda.com/blog/using-pip-in-a-conda-environment). So what exactly would you want to change? – Mayou36 Feb 03 '21 at 17:42
  • well for one conda could try to detect this, and notify the user that there might be problems when going ahead. It would save people like me some time discovering it the hard way. – StarShine Feb 04 '21 at 09:06
  • @StarShine while I agree and share the frustration with you more than you may can guess - I figured that out years ago also the hard way - I think there is nothing to add in the answer. Or do you have an idea on what to add? But I agree that conda could try to be more pro-active on this, maybe want to open an issue there? – Mayou36 Feb 04 '21 at 15:24
  • Slow resolving may be an issue, `conda update --all -c conda-forge --solver=libmamba` (requires `conda-libmamba-solver`, which makes conda like mamba without the nice logo) – Matteo Ferla Feb 16 '23 at 17:16
  • This didn't work for me! It broke a few packages that I later fixed with `pip` – vyi May 31 '23 at 06:36
  • @vyi so first, if you used pip afterwards, you maybe were lucky to patch something but it's hard to know if it is correct now. I hope you used, as adviced, a conda environment, then you should be able to simply remove that, re-create and re-install. If it broke, I assume this is because a package didn't put the correct dependencies - we're all human developers and this happens. But this is independent of the actual issue. – Mayou36 Jun 01 '23 at 14:51
24

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.

InLaw
  • 2,537
  • 2
  • 21
  • 33
  • 3
    This answer assumes: 1. you installed miniconda3 with the default name and path (and not, say anaconda) 2. that you created an environment "py35". You may specify that further as beginners, who this answer should be targeted at (in my opinion), can get easily confused. Furthermore you seam not really to answer the question, as this may *still* does not allow him to upgrade. And that is his goal. – Mayou36 Apr 30 '18 at 14:07
  • Of course, let me ask them individually: a) "ONLY within a specific version": this refers to the Python version, not to packages, right? Or can you cite this please? – Mayou36 May 25 '20 at 09:31
  • b) "In the documentation you will find [...]": this refers clearly to the Python version. It has nothing to do with the question, correct? Or why do you post this? How is this statement relevant? – Mayou36 May 25 '20 at 09:33
  • c) `conda update -n ENVIRONMENT --all`: I agree that this is what he/she usually wants to use, not to update the base environment. However, I don't find an explanation in your answer on this at all, it is just written and does not refer to the difference of using the command of the op in the base environment. – Mayou36 May 25 '20 at 09:42
  • d) "If you only want to update almost all, you can create a pin file": this is a nice information. But it is not what OP asked for. He wants to know _why_ he cannot update _all_. He does not want to pin down versions. So it does not add to the answer, does it? – Mayou36 May 25 '20 at 09:43
  • 1
    e) "You should not do update --all": Why not? I do think that this is the right way to go and what the OP wants (modulo maybe in a virtual env), so why would you say he should not do it? What does the cloning of an environment has to do with it? – Mayou36 May 25 '20 at 09:45
  • f) NixOS: why exactly are you referring to a specific (niche) linux distribution and their packages? If you want to force incompatible dependencies to be installed, there are other ways (`force` flag in anaconda, pip). Why would you think that OP is using NixOS? – Mayou36 May 25 '20 at 09:47
  • @Mayou36 sorry, I understand that as a beginner (and Anaconda user) lost of technologies and methods are "not logical". Each of your comments is an own stackoverflow question, if you open such I can answer you in detail. PLEASE do not SPAM. – InLaw May 26 '20 at 05:04
  • I think you misunderstand. These are not "questions" that I would like to have answered since I don't know better but rather critics on your answer. As I wrote above, I think this answer contains so many incorrect statements, I've listed them above. I am not a beginner and very well aware of the problem the OP encounters; maybe you want to have a look at the accepted (my) answer above. I still would like you to address my points and/or change your answer accordingly. – Mayou36 May 26 '20 at 08:44
3

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.

1

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:

  1. Create a new environment for each project

  2. 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.

Anna Pas
  • 41
  • 3
  • This does not provide an answer to the question. Once you have sufficient [reputation](https://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](https://stackoverflow.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/late-answers/29963452) – diggusbickus Sep 30 '21 at 22:46
0

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

David
  • 325
  • 2
  • 12
  • 1
    But how do you select all to update when there are too many to select individually? – beldaz Apr 13 '19 at 21:57
  • @beldaz, I tried to 'solve' it by selecting all 141 packages in the last column with 'Version', and then press Apply. Not sure if it works :( . Then I just opened Anaconda console by pressing Anaconda Prompt – Pieter21 Apr 15 '19 at 08:34
  • Run as Admin may also be required – Pieter21 Apr 15 '19 at 08:46
  • 2
    This won't solve the actual problem neither, read the accepted answer about dependency conflicts. – Mayou36 May 11 '19 at 21:24
-3

To update all possible packages I used conda update --update-all

It works!

rdas
  • 20,604
  • 6
  • 33
  • 46
nein nein
  • 11
  • 1
  • 6
    No, it does "not": if you reread the OP, dependency conflicts are encountered. This answer does not solve _nor_ explain anything – Mayou36 Sep 27 '19 at 08:31
-13

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

Dennis Vash
  • 50,196
  • 9
  • 100
  • 118
Mantakeke
  • 1