Two types of blocked updates/upgrades of packages in 1.8

General Usage
1

In the latest release candidate (v1.8.0-rc3) I can notice a new feature of the package manager, namely, after listing all packages in the given environment with status, I get this as the final line:

Info Packages marked with ⌃ and ⌅ have new versions available, but those with ⌅ cannot be upgraded. To see why use `status --outdated

Following the advice, I type

(@v1.8) pkg> status --outdated
Status `~/.julia/environments/v1.8/Project.toml`
⌃ [961ee093] ModelingToolkit v8.11.0 (<v8.18.6)
⌅ [f27b6e38] Polynomials v2.0.25 (<v3.1.6): IntervalRootFinding
⌃ [0c5d862f] Symbolics v4.3.0 (<v4.10.3)

Now, what have I learnt? While I know how to interpret the fact that a newer version of Polynomials is blocked by IntervalRootFidoing, I have no idea how to interpret the blocking of ModelingToolkit and Symbolics. The last line of status listing explicitly says that Polynomials cannot be updated, but doesn’t this say, albeit implicitly, that ModelingToolkit and Symbolics can? But how can I learn what is blocking the update?

3 Likes
2

Have you done up?

In general to learn what (if anything) block installation of a specific update, do add Package@X.Y.Z to add a specific version. In your case e.g. add Symbolics@4.10

(Incidentally it looks like you’re installing everything into your default environment, which is generally a bad idea - you should work with project specific environments instead and keep the default environment for dev tools like Revise, Pluto, IJulia etc. to avoid version conflicts as much as possible and benefit from reproducibility of your analysis environments).

3 Likes
3

Yes, I have done up before reporting this issue.

Thanks for the advice to use add Symbolics@4.10. Indeed, it does produce some detailed report about unsatisfiable requirements.

You have correctly identified that I still keep the bad habit of having one large env for everyday work. I should follow your advice to keep just a light one and I easily believe that this type of problems would be reduced.

Anyway, my original issues can perhaps still be regarded valid, cannot it? In the listing following the status command, some package are labelled as unupgradable. And there are two types of such packages, distinguished with graphical symbols. While status --outdated does help to find the source of the blocking for one type, it says nothing about the other type. Perhaps some better wording of the final sentence after the status listing might help dispel confusion.

1 Like
4

Yes, I admit I don’t really see why the tilde without bar is shown when a package is held back, maybe I’ve been sitting in front of my screen for too long but I can’t work it out from the explanation in the docs:

https://pkgdocs.julialang.org/dev/api/#Pkg.status

which explicitly say:

Packages marked with ⌃ have new versions that can be installed, e.g. via Pkg.up. Those marked with ⌅ have new versions available, but cannot be installed due to compatibility conflicts with other packages. To see why, set the keyword argument outdated=true.

So it seems you shouldn’t see ^ when conflicts prevent an update. Maybe @kristoffer.carlsson can help?

2 Likes
5

There is nothing directly holding the package back but there might be other reasons why the package cannot be upgraded. Without doing a full resolve it is impossible to tell so the ^ is a best effort.

1 Like
6

Can you mention what those reasons might be?

Would a manual Pkg.resolve() help settle these, so that they either become actually upgradeable or marked with ⌅?

7

This is a caret ^. This is a tilde ~.

This comment is late and unnecessary, but the Swedish proverb “fel ska va fel” (“wrong must be wrong”) is my core directive.

2 Likes
8

Upgrading the package might downgrade some other package is one example.

In theory it would be possible to go through all packages with ^, check with the resolver if they can be upgraded to a higher version without changing anything. In a large project with many outdated packages this might get pretty expensive though.