Hi,
In GMT.jl the GMT_jll version is been hold by something to a version one year old.
If I force the install with ] add GMT_jll I see (checked in 3 different computers)
st
...
[b68b8c3f] GMT_jll v6.6.0+0
but newest version is v6.7.1 that dates from 4 days ago. I noticed that the build_tarballs.jl was depending on Julia 1.6. I did submit a new build with a compact update to Julia 1.10 but I’m still waiting for its merge and honestly I have many doubts that this will solve the issue.
So, my question is still, what may be holding the the GMT_jll version into a version that is ~1 year old and, mainly, what can I do to fix this?
I managed to half fix this situation. Apparently compat bounds in totally unrelated to GMT_jll (GALD_jll in this case) can hold the update. But things continue screwed still. Although a [ up (but [up GMT not) is able to update the .julia\environments\v1.??\Manifest.toml` to
[[deps.GMT_jll]]
...
version = "6.7.1+0"
this keeps being totally ignored in further [ upand only deleting that file and running Pkg.instantiate() seems to finally solve the updating issue.
I mean, GMT_jll has lots of dependencies. Any other package that also uses those dependencies, but has a stricter requirement could hold it back.
If I only install GMT_jll and nothing else into a fresh environment, I get the latest version. But you need both the activated environment and your global environment to not have those limiting packages added to it.
Well GMT has only 2 non-stdlib and non-_jll: Tables & PrecompileTools
plus these *_jll
GMT_jll
GDAL_jll (only this one is a big dependency)
PROJ_jll
Ghostscript_jll
LASzip_jll
Leptonica_jll
of those only GMT depends on GMT_jll, nothing else depends on it. So I miss to understand why any other _jll dependency may hold it
I also tried to update the GMT_jll alone, with mixed results. But one of my points is, the environment Manifest has now the latest version, but that is not the version that is use. Unless I delete the whole manifest and do a Pkg.instantiate(), which is something I would rather not have to tell students that they have to do.
Assuming this is about v1.43.1 instead of v1.43.2 where this does happen in a fresh environment, GMT@1.43.1 bounds GDAL_jll = "302.1000,303.1100" while GMT_jll@6.7.1 bounds GDAL_jll = "304.1200". Those bounds aren’t compatible to Pkg:
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
⌃ [5752ebe1] GMT v1.43.1
Info Packages marked with ⌃ have new versions available and may be upgradable.
(testgmt) pkg> add --preserve=direct GMT_jll@6.7.1
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package GDAL_jll [a7073274]:
GDAL_jll [a7073274] log:
├─possible versions are: 3.0.3 - 305.1300.301 or uninstalled
├─restricted by julia compatibility requirements to versions: [3.0.3 - 3.2.1, 300.202.100 - 305.1300.301] or uninstalled
├─restricted by compatibility requirements with GMT [5752ebe1] to versions: 302.1000.0 - 303.1100.500
│ └─GMT [5752ebe1] log:
│ ├─possible versions are: 0.4.0 - 1.43.2 or uninstalled
│ ├─restricted to versions * by project [486cb586], leaving only versions: 0.4.0 - 1.43.2
│ │ └─project [486cb586] log:
│ │ ├─possible versions are: 0.0.0 or uninstalled
│ │ └─project [486cb586] is fixed to version 0.0.0
│ └─restricted to versions 1.43.1 by an explicit requirement, leaving only versions: 1.43.1
└─restricted by compatibility requirements with GMT_jll [b68b8c3f] to versions: 304.1200.0 - 304.1200.400 — no versions left
└─GMT_jll [b68b8c3f] log:
├─possible versions are: 6.4.0 - 6.7.1 or uninstalled
└─restricted to versions 6.7.1 by an explicit requirement, leaving only versions: 6.7.1
(testgmt) pkg> add GMT_jll
Updating `C:\Users\Benny\testgmt\Project.toml`
⌃ [b68b8c3f] + GMT_jll v6.6.0+0
Manifest No packages added to or removed from `C:\Users\Benny\testgmt\Manifest.toml`
v1.43.2 fixed that, but the rest of your environment stack can still obstruct it. What does add --preserve=direct GMT_jll@6.7.1 say in that case?
I think the latter has the same rules as Pkg.update and defaults to not updating any of GMT’s dependencies.
If packages are given as positional arguments, the preserve argument can be used to control what other packages are
allowed to update:
• PRESERVE_ALL (default): Only allow pkg to update.
• PRESERVE_DIRECT: Only allow pkg and indirect dependencies that are not a direct dependency in the project
to update.
• PRESERVE_NONE: Allow pkg and all its indirect dependencies to update.
Thanks for looking into this. I don’t have much more computers where to test it, but in one with 1.43.2 and where the environments/manifest already has GMT_jl 6.7.1
That last v"6.6.0" means the GMT_jll was not updated. Only deleting the environments/…/Manifest.toml and do Pkg.instantiate() will solve it. I don’t find this nothing normal.
Any chance you already loaded GMT before the GMT_jll update? The rest of the process would be stuck with the loaded version of GMT_jll. v1.12 warns about loaded packages, and I don’t remember if v1.10 did.
Anyways here’s GMTver for a couple of environments. I thought JLL versions matched their underlying library’s versions based on this section, was I mistaken? In any case, that’s not a Pkg version resolution problem anymore.
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
⌃ [5752ebe1] GMT v1.43.1
⌃ [b68b8c3f] GMT_jll v6.6.0+0
Info Packages marked with ⌃ have new versions available and may be upgradable.
julia> using GMT; GMTver
v"6.7.0"
(testgmt) pkg> st
Status `C:\Users\Benny\testgmt\Project.toml`
[5752ebe1] GMT v1.43.2
[b68b8c3f] GMT_jll v6.7.1+0
julia> using GMT; GMTver
v"6.8.0"
What you get is the correct behavior. I think I reproduced that in the Linux Codespaces machine, but not in at least two Win+Julia1.10 computers, where previous older GMT.jl versions were installed and I did a ] up.
Anyway, thanks for your trials.