Very fancy package updating 1.6

I’ve been using v1.6 for day-to-day work for a month or so. I’m primarily on Windows, so this issue pushed me to work with a Linux v1.6 binary installed on WSL2, but it seems to be fixed now that this PR’s been merged. Julia’s Linux binaries are typically the most robust, since many of the core devs use it as their primary platform.

Not yet. I had to wait for LoopVectorization to catch up.

Update: it looks like I will have to wait a little bit longer. 1.6 has some difficulties installing/updating the registry on Windows 10. https://github.com/JuliaLang/julia/issues/38691

If you happen to depend on LoopVectorization, 1.6 is still out of reach, since this package hasn’t been updated yet.

1 Like

LoopVectorization 0.9 works on 1.6 (but the Windows registry issue could be another show stopper until it gets fixed).

3 Likes

Downloads are much faster too since we use libcurl and can share and reuse TCP+TLS connections.

8 Likes

You are right. Sorry. It is the damn dependencies: it pulled 8.2.6, which I thought was okay. But apparently the new one is 0.9…

I will then rephrase my previously stated opinion: we need some way of detecting newer package versions.

4 Likes

What do you mean?

So the case here is FinEtools.jl when run in 1.6 needs LoopVectorization 0.9. But in 1.5 it needs 0.8.
And, when tested in 1.6, the test fails, because 0.8 LoopVectorization is requested.

So, it would be helpful if I could run a command say Pkg.newer() that would detect all newer versions of the packages requested in the current environment. I believe that Pkg.update() will not do that, since it is quite happy to report that given the requirements in the project, all packages are okay.

1 Like

It isn’t a matter of “detecting” new versions, Pkg.update updates the registry and is already aware of all new versions. However, Pkg.update respects all compatibility requirements in your environment. If it doesn’t update a package to a newer version, probably it’s because something else is holding it back because of compatibility bounds. What would be useful is a tool to easily investigate why a package is held back.

3 Likes

Are you sure? If the project asks for 0.8, are you certain that if 0.9 is available it will update? I haven’t seen that.

One possible fix would be for up to give warnings for packages that don’t get their newest release installed (or maybe their newest feature release according to semvar)

3 Likes

I’m certain that if in the environment there aren’t compatibility bounds that prevent installation of a newer version, the package will be updated. If in your environment you’re saying “this is compatible only with version 0.8 of package ABC” then no, package ABC will not be update to v0.9, because that would be breaking according to semver. Again, this has to do with compatibility bounds, not Pkg.update not knowing that a new version has been released

1 Like

It may be that I’m not using the versions correctly. My project says

LoopVectorization = "^0.8"

What should it say so that I would have gotten 0.9 if that was available?

LoopVectorization = "0.8, 0.9"

If this is for a package, you should probably look into https://github.com/JuliaRegistries/CompatHelper.jl, which does exactly this for you :slight_smile:

1 Like

Okay, but you understand that when the package was tested last, there was no 0.9. Hence, my requirement was 0.8 since that was the latest. Now when I switch to 1.6, 0.9 becomes the latest. However, the package update will not inform me that there is a newer version to which I should upgrade if I want to run a 1.6. That is my point.

3 Likes

I know that the package manager doesn’t do that and I’m not convinced it’s always a good idea to show this kind of updates, casual users will probably see a lot of them and ignore them anyway. Package developers might find such feature more useful, but what I’m trying to tell you is that if you’re a package developer, CompatHelper does exactly this with an automatic pull request to your package :slightly_smiling_face:

2 Likes

I see what you’re saying. I will check it out. Thanks!

1 Like

There is also https://github.com/xiaodaigh/PkgVersionHelper.jl but I have not used it. I just remember seeing it posted here.

1 Like

https://github.com/GunnarFarneback/PackageCompatUI.jl is also useful for this purpose. Packages that have newer versions than specified by [compat] are shown in yellow and you can update Project.toml directly from the UI.

(This package is Julia 1.6 only and won’t be registered until 1.6 has been released.)

3 Likes