A guide: How to handle "ERROR: Unsatisfiable requirements detected ..."

Approximately once or twice a week (based on my feelings, not actual stats), I see a post asking about error: How to handle “ERROR: Unsatisfiable requirements detected …”

It’s so common that I think it’s time for a systematic break-down of the issue.

After reading this, you should be able to understand why this happens? and how to handle it.

Deciding a package version
Typically, a Julia package exists in multiple semver version. E.g. 0.1, 0.2, 0.3 etc. In general, when installing a package, the package manager will try to install the latest version of a package.

However, installing the latest version is not always possible due to dependency requirements.

For example, if the latest version of PkgA, say v0.5, requires PkgB v0.4 or lower. Even if PkgB v0.5 exists, install PkgA will only install PkgB v0.4, because the package manager figured out that if it installs PkgB v0.5 then PkgA v0.5 can be installed due to dependency requirements.

As you can imagine, there is a complex web of package dependencies and hence the package manager needs to figure which version of a package can be installed or not. And sometimes, the package manager can’t figure out a set of compatible package versions to install and hence why you see THE error!

This is a recent example:

ERROR: Unsatisfiable requirements detected for package Flux [587475ba]:
 Flux [587475ba] log:
 ├─possible versions are: 0.11.0 or uninstalled
 ├─Flux [587475ba] is fixed to version 0.11.0
 └─restricted to versions 0.10 by GeometricFlux [7e08b658] — no versions left
   └─GeometricFlux [7e08b658] log:
     ├─possible versions are: 0.5.2 or uninstalled
     └─GeometricFlux [7e08b658] is fixed to version 0.5.2

You are will see that there are four indentation levels. The first level (unindented), says Flux [587475ba] log: so it is going to describe the package manager’s experience when trying to install Flux.jl

Firstly you should notice that possible versions are: 0.11.0 or uninstalled is the first sentence of the next level of indentation. Becuase this identation under Flux it is describing that only 0.11.0 of Flux is available. This is odd, because obviousiously Flux 0.10, and 0.9 etc exists. So the fact that it’s so restrictive about the version of Flux means that the user has either deved or pined the version, or tried to install a specific branch of Flux. E.g. trying to install the master branch of Flux can do that.

The next line is telling too Flux [587475ba] is fixed to version 0.11.0 which suggest the same thing as above.

Now the next line is interesting restricted to versions 0.10 by GeometricFlux [7e08b658] — no versions left. Because it’s under the Flux indentation, it is saying trying to apply GeometricFlux dependency restriction, then there is no possible version of Flux left!

Why? See the next indentation levels, which says that Geometric Flux’s possible versions is 0.5.2 due to it being fixed to 0.5.2. So why does that restrict Flux? If you look at the Project.toml for Geometric, I bet you will that it supports up to Flux 0.10 only and hence can’t satisfy Flux0.11!

So how to handle this type of things?
Firstly, the above is a rather simple example, so it still takes practice to understand more complicated example. But keep in mind that it’s due to unsatisfiable dependencies. Hence to handle it we need make the dependencies have a chance of being satisfiable.

  1. Think about downgrading some packages. In the above example, Flux is pinned at 0.11 by the master branch, so perhaps you can Flux the requirement for Flux to 0.10 by ]rm Flux then ]add Flux (technically you can skip ]rm but it’s cleaner to me.
  2. See if main branch of some dependencies already support a higher version. In the above example, maybe the main beach of GeometricFlux already supports Flux 0.11, so if you can’t wait installing that branch would help
  3. Also, the package you install the more likely you will run into issues like this. So another approach to reduce errors like this is to always work inside a project environment e.g. ]activate another-env and install only the package you need for the project into it.


which is now merged in master and can be read at



This is definitely a stumbling block that needs ironing out. I followed your instructions but unfortunately not even uninstalling all the packages in my env helped in Julia 1.5.4. However using the related issue here Getting an error with the Colors package - #2 by fredrikekre I could fix it after deleting the entire .julia/registries folder and its contents, then exiting and restarting Julia.

I think sharing my experience here may be useful. I have often encountered this kind of error recently. The reason for its high frequency is this workflow of mine:

  1. I change a local copy of a Julia project and update its dependencies.
  2. I commit the changes to a git repository (including the Manifest.toml).
  3. I update a copy of the same project on a test server using git pull.
  4. The Julia installation on the server has an out-of-date registry.
  5. The registry does not recognize the versions used on the updated Manifest.toml.

The solution for me is simply executing:

$ julia
julia> import Pkg; Pkg.Registry.update(); Pkg.activate(); Pkg.instantiate();

inside the folder with the updated Manifest.toml.

That’s a completely unrelated issue though, you’ve got a corrupted registry

I’d disagree that is is “completely unrelated”. Although the fix/solution are not related, my issue gave the same error message containing “Unsatisfiable requirements…” and this issue was one of the first that came up after a Google. Hopefully this post will help some where @xiaodai’s fix didn’t work.

It also outlines how Julia at the moment isn’t able to run autotests in the background to check if the registry is corrupt before giving “Unsatisfiable requirements…” error messages.

This is a rather generic error message that can happen for many reasons.