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
(JuliaTutorial) pkg>
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.
Not restricted by an explicit version requirement for this package.
or
No explicit requirement, all versions of the package possible.
That part really just means that the current julia version is incompatible with the versions this package works with… Not sure how that can be formulated better?
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: …”.
So, if the package is unhappy with the julia version here, how come that with Julia 1.7.2 I’m able to activate and instantiate its environment, run tests, and there is no warning, much less an error.
julia> versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
OS: Windows (x86_64-w64-mingw32)
CPU: Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-12.0.1 (ORCJIT, icelake-client)
Environment:
JULIA_DEPOT_PATH = C:/Users/pkonl/Sublime_Julia_portable/assets/.julia-1.7.2-depot
JULIA_SSL_CA_ROOTS_PATH =
julia> using Pkg; Pkg.activate("."); Pkg.instantiate();
Activating project at `C:\Users\pkonl\Documents\00WIP\FinEtoolsHeatDiff.jl`
shell> cat Project.toml
name = "FinEtoolsHeatDiff"
uuid = "972d1c22-8bdd-11e9-11cf-cdcb7577b041"
authors = ["Petr Krysl <pkrysl@ucsd.edu>"]
version = "1.0.2"
[deps]
Arpack = "7d9fca2a-8960-54d3-9f78-7d1dccf2cb97"
FinEtools = "91bb5406-6c9a-523d-811d-0644c4229550"
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
Profile = "9abbd945-dff8-562f-b5e8-e1ebf5ef1b79"
SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
Statistics = "10745b16-79ce-11e8-11f9-7d13ad32a3b2"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
[compat]
Arpack = "^0.5"
FinEtools = "^5"
julia = "~1.6"
shell>
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).
(typing