I would not be surprised if novices were stumped. I certainly am:
(JuliaTutorial) pkg> add FinEtoolsHeatDiff
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package FinEtoolsHeatDiff [972d1c22]:
FinEtoolsHeatDiff [972d1c22] log:
├─possible versions are: 0.4.0-1.0.2 or uninstalled
├─restricted to versions * by an explicit requirement, leaving only versions 0.4.0-1.0.2
└─restricted by julia compatibility requirements to versions: uninstalled — no versions left
What I find particularly puzzling is restricted to versions * by an explicit requirement.
Doesn’t this mean that the version can be anything (*)?
How does one debug something like this? It happens to me from time to time, and I can usually get this to work by some fiddling with the projects or the julia depot, but there may be a systematic way that I don’t know about.
The thing is this could mean that (a) the current julia is unhappy with the version of the package, or that (b) the package is unhappy with the version of the julia. So in this case I believe it should say “restricted by package requirements on julia version to versions: …”.
Why would it? ~1.6 means “any version 1.6.x between 1.6 and 1.7, excluding 1.7”. So it’s a right half open interval.
Does it have a julia version in its Manifest.toml (if it has one)? A cursory look suggests it’s a 1.6 style Manifest, which I’m not sure forces julia version restrictions yet (though it should be able to read it…). You may want to do Pkg.resolve() or generate a new one by deleting it and re-instantiating.
The option (a) is impossible if you take into account the design of Julia (and most languages with a builtin package manager). The language and its standard library cannot depend or be aware of other packages to be unhappy with them, it is only the packages that are aware of Julia version and can be unhappy about it.
Ha! I stumbled into the same case just today, trying to add StatPlots.jl, and I remained really puzzled because even looking into the repository on Github I couldn’t find the source of incompatibility… until I realized that the repo had changed its name to StatsPlots.jl three years ago, so the registry has entries for both the old (incompatible) StatPlots, and the current compatible StatsPlots !! (typing StatPlots in the Github URL didn’t fail, but silently redirected to the new repository name).