I recently updated to 1.8.2, but I think this was also happening previously.
I have a package without any dependency forcing it to a lower version, but whenever I run update, the package manager proceeds to downgrade it. I have to proceed to manually update it every time I run a general update, and another round of precompilation follows. Honestly, this exquisitely infuriating. Am I missing something here, and this is happening for some reason I am not aware of?
The package in question here is the MAT.jl package. The Mocking.jl package also seems to be stuck without any restriction, but that’s not main offender here.
I’ll copy a sample of a REPL session where that happens:
(@v1.8) pkg> update
Updating registry at `~/.julia/registries/General.toml`
Installed LabelledArrays ──── v1.12.3
Installed AbstractTrees ───── v0.4.3
Installed HTTP ────────────── v1.5.1
Installed VectorizationBase ─ v0.21.54
Updating `~/.julia/environments/v1.8/Project.toml`
[cd3eb016] ↑ HTTP v1.5.0 ⇒ v1.5.1
Updating `~/.julia/environments/v1.8/Manifest.toml`
[a74b3585] + Blosc v0.7.3
⌅ [f67ccb44] ↓ HDF5 v0.16.12 ⇒ v0.13.6
[cd3eb016] ↑ HTTP v1.5.0 ⇒ v1.5.1
[a98d9a8b] ↑ Interpolations v0.13.6 ⇒ v0.14.6
[2ee39098] ↑ LabelledArrays v1.12.2 ⇒ v1.12.3
⌃ [23992714] ↓ MAT v0.10.3 ⇒ v0.8.1
[3d5dd08c] ↑ VectorizationBase v0.21.53 ⇒ v0.21.54
[0b7ba130] + Blosc_jll v1.21.1+0
[5ced341a] + Lz4_jll v1.9.3+0
Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
Precompiling project...
41 dependencies successfully precompiled in 417 seconds. 367 already precompiled.
(@v1.8) pkg> status --outdated -m
Status `~/.julia/environments/v1.8/Manifest.toml`
⌅ [ab4f0b2a] BFloat16s v0.2.0 (<v0.4.2): CUDA
⌅ [f67ccb44] HDF5 v0.13.6 (<v0.16.12): MAT
⌅ [ef3ab10e] KLU v0.3.0 (<v0.4.0): LinearSolve
⌃ [23992714] MAT v0.8.1 (<v0.10.3)
⌃ [78c3b35d] Mocking v0.7.2 [<v0.7.4], (<v0.7.3)
⌅ [8ea1fca8] TermInterface v0.2.3 (<v0.3.3): Metatheory
⌅ [aabc7e14] MariaDB_Connector_C_jll v3.1.12+0 (<v3.3.2+0): MySQL
⌅ [214eeab7] fzf_jll v0.29.0+0 (<v0.30.0+0): JLFzf
(@v1.8) pkg> update MAT Mocking
Updating registry at `~/.julia/registries/General.toml`
No Changes to `~/.julia/environments/v1.8/Project.toml`
Updating `~/.julia/environments/v1.8/Manifest.toml`
[a74b3585] - Blosc v0.7.3
[f67ccb44] ↑ HDF5 v0.13.6 ⇒ v0.16.12
[23992714] ↑ MAT v0.8.1 ⇒ v0.10.3
[0b7ba130] - Blosc_jll v1.21.1+0
[5ced341a] - Lz4_jll v1.9.3+0
Precompiling project...
3 dependencies successfully precompiled in 10 seconds. 402 already precompiled.
(@v1.8) pkg> status --outdated -m
Status `~/.julia/environments/v1.8/Manifest.toml`
⌅ [ab4f0b2a] BFloat16s v0.2.0 (<v0.4.2): CUDA
⌅ [ef3ab10e] KLU v0.3.0 (<v0.4.0): LinearSolve
⌃ [78c3b35d] Mocking v0.7.2 [<v0.7.4], (<v0.7.3)
⌅ [8ea1fca8] TermInterface v0.2.3 (<v0.3.3): Metatheory
⌅ [aabc7e14] MariaDB_Connector_C_jll v3.1.12+0 (<v3.3.2+0): MySQL
⌅ [214eeab7] fzf_jll v0.29.0+0 (<v0.30.0+0): JLFzf
(@v1.8) pkg> update Mocking
Updating registry at `~/.julia/registries/General.toml`
No Changes to `~/.julia/environments/v1.8/Project.toml`
No Changes to `~/.julia/environments/v1.8/Manifest.toml`
(@v1.8) pkg> update
Updating registry at `~/.julia/registries/General.toml`
Installed AbstractAlgebra ─ v0.27.6
No Changes to `~/.julia/environments/v1.8/Project.toml`
Updating `~/.julia/environments/v1.8/Manifest.toml`
[c3fe647b] ↑ AbstractAlgebra v0.27.5 ⇒ v0.27.6
[a74b3585] + Blosc v0.7.3
⌅ [f67ccb44] ↓ HDF5 v0.16.12 ⇒ v0.13.6
⌃ [23992714] ↓ MAT v0.10.3 ⇒ v0.8.1
[0b7ba130] + Blosc_jll v1.21.1+0
[5ced341a] + Lz4_jll v1.9.3+0
Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ are restricted by compatibility constraints from upgrading. To see why use `status --outdated -m`
Precompiling project...
8 dependencies successfully precompiled in 119 seconds. 400 already precompiled.
which would like to be the default, or at least tried first. There are more options including “tiered Use the tier which will preserve the most version information (this is the default)” which doesn’t seem to be concerned with downgrading vs upgrading…
I think this part “will preserve the most version information”. I would rather want more upgraded, and none downgraded. I’ve seen a case where I didn’t get the latest version could still upgrade to it, so I wouldn’t rule out a bug in the algorithm.
I normally would assume (blindly) that if a package needs to be downgraded for compatibility with a newly installed one, I would accept that and move along, as it would be safer. I am very confused as to why this package would be downgraded without any seeming compatibility restriction. However, I don’t think it’s also safe to avoid automatic downgradings just because, they might be warranted.
If that’s the case, at least it would be satisfactory if it could be confirmed. I’ll just wait for a few more replies, if possible, before trying to report this in the repo.
I mean it could do better (I confirmed; and you too really seemingly). It’s not a bug in a strict sense, since it DID install what you wanted… and you (the default) just didn’t prevent downgrades. I just wish for a better default, doing better is possible, but would slow the algorithm down.
I don’t think I agree with your interpretation of this not being a bug and slowing down the algorithm.
From my point of view, any package manager should only downgrade a version you already have installed if a newly added package requires an older version for compatibility. In this case, it is downgraded without such a reason. We could assume that a restriction exists and the bug is that it is not displayed in the REPL. If that was the case, then manually updating the downgraded package would be stopped, which doesn’t happen. The other case is that there’s a bug in the that step too, and it fails to detect the restriction at that step and allows the user to update the package.
Also, the microseconds it takes to check version compatibility in toml files vs the time it takes to precompile a bunch of files all over again everytime this bug occurs are such that I think a “heavy but safer” compatibility algorithm is worth it.
But we’re discussing hypothetically, since I myself would like someone else to help us confirm if this is a bug or not.