Personally I’d find an option like this extremely useful (agree an option is the right way to go). It could look something roughly like this, to mirror what would happen if you actually did a pkg> up
(@v1.5) pkg> st --upgradeable
Status `~/.julia/environments/v1.5/Project.toml`
[c52e3926] Atom v0.12.24 ⇒ v0.12.28 (latest)
[6e4b80f9] BenchmarkTools v0.5.0 (latest)
[052768ef] CUDA v2.0.0 ⇒ v2.1.0 (newer v2.3.0 exists)
...
Color would be useful too, maybe green if already at the latest version, blue if its upgradeable in this environment to the latest possible version, or yellow if a newer version exists but something is holding it back.
I think it’s informative rather than actionable. If I’m expecting to be on the current release of some dependency and that’s what I’m reading the docs for, it might take me a while to figure out why something doesn’t work because I’m actually on an older release. That said, this only matters for direct dependencies.
While not recommended, I’m willing to bet that most users have at least one environment that’s their repl experimentation environment where nothing is managed. (honestly that’s probably the only environment for 80% of beginners).
It’s very rare that I use separate Project/Manifest files and use the environment infrastructure like it was supposed to be used. Most of the time I simply add a package to my global environment. It would be nice to somehow get a message saying Package xx can not be upgraded to the latest version because of package yy. If package yy is something I used for 10 minutes four months ago, I will delete it… if yy is a highly used package, I may then finally move to a different environment.
Seems like this would be a boon to maintainers, too–I see a lot of issues filed that amount to “why can’t I update your package?”, which often leads to the maintainer spending time to reproduce and pin down the compatibility conflict. It’d be great to have a built-in tool to take the load off developers.
Not really adding to the discussion, but I use separate envs almost exclusively (nothing but Revise in the global env) after being burned repeatedly by package compat issues in other languages. It’s cool to see how many different workflows Pkg can accommodate.
