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.
- 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 Fluxthen]add Flux(technically you can skip]rmbut it’s cleaner to me. - 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
- 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-envand install only the package you need for the project into it.
