Shouldn't there be a warning when package can't update to latest?

Internals & Design
1

Hellooo,

So I just used up Plots which updated it to v1.7.3. When I went to the github page, I saw that the latest release was 1.9.1.
So I used up Plots@v1.9.1 to force installation of the latest release and to see what dependency was incompatible.

I was just thinking that it would be nice to be warned when the latest release can’t be installed. I remember when I started julia, I used Plots 0.1 for a while before noticing it…

Has this been discussed ?

10 Likes
2

Yes, a couple of days ago here:

See in particular

3

If you need a specific versoin of Plots, it is recommended to put that into your Project file, for example

[compat]
Plots = "1.9"

will force you to get the 1.9.x version of Plots.

4 Likes
4

Well the issue I have is more about being aware of the newest version. I don’t want to subscribe to all my packages’ mail lists.

For packages like Plots, I usually want the latest because the version is not important to my work.

2 Likes
5

There could be a Pkg command that shows what packages are not on the latest version. I don’t think it should be in the default output though.

11 Likes
6

Why not mark it in the status command output? That would seem to be a natural place for people to inspect the version of packages (it could even just be changing the color for packages that aren’t on the latest version).

7 Likes
7

In most cases, it would not actionable by an average user. The resolver already gives you the latest versions that are possible based on your compatibility constraints.

8

For lots of users, the “constraints” are just whatever packages they happen to ever have installed. As such, knowing “I’m stuck on an old version of CSV because xyz that I tested for 5 minutes 4 months ago doesn’t support the new version” is really useful.

13 Likes
9

It’s not really recommended to put every package in one big environment for reasons like this.

Also, I agree it can be useful, that’s why I am suggesting e.g. a --compat flag to status.

7 Likes
10

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).

25 Likes
11

Would it be so bad to have the newest version in parentheses after the actual version that was updated to?

12

I think so, yes. For example, I think a lot of new users would open issues on package repos where they do not get the latest version, even though that package is not at all to blame.

3 Likes
13

Well in my case this wasn’t even the problem. The compatibility issue was coming from a GR artifact, for some reason I had to update and build it manually.
This sort of thing can happen even if you maintain a clean environment.

Sure a flag could do it but I’d basically use it every time I update my “utility packages” e.g. those that are not core to my work but that I use to analysis.

1 Like
14

What if we also put blame on the package(s) holding it back? That way we’d get issues in the right package to keep the ecosystem up to date.

1 Like
15

Yeah, but now you need to put much more info in there and it is starting to get spammy. This is why I suggest a separate flag to give you all that information, when you want it .

2 Likes
16

Maybe I underestimate how many people would file bug reports because of this. But in general, I’m not for keeping people uninformed by default, and on the contrary, a lot of bug reports are filed because people have for some reason not been updated to the fixed version, and don’t know.

1 Like
17

Given how difficult the UX for something like this is, I don’t see any harm in starting with an opt-in command. Other package managers do this already, see e.g. npm-outdated | npm Docs.

1 Like
18

Maybe it would also be nice to have an easier way to force installing the latest update, instead of having to look up the version number and then plugging that in. So if someone wanted to try to update to the latest version, they could do something like

]add SomePackage@latest
6 Likes
19

As a relatively new user (~1 yr), I can recall clearly the frustrations I felt when I first discovered that a package was being held back by another. There didn’t seem to be a good way to figure out which package was causing the hold. It would be great to have a package manager command to review all packages in the environment Project.toml and identify 1) which packages are being held behind the current release; & 2) which package is responsible for the hold. The user can then decide what to do.

13 Likes
20

Relevant issue: https://github.com/JuliaLang/Pkg.jl/issues/1655

2 Likes