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
⌃ [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
Symbolics. The last line of
status listing explicitly says that
Polynomials cannot be updated, but doesn’t this say, albeit implicitly, that
Symbolics can? But how can I learn what is blocking the update?
Have you done
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.
(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).
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.
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:
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
So it seems you shouldn’t see
^ when conflicts prevent an update. Maybe @kristoffer.carlsson can help?
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.
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
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.
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.