Specifying "recommended" Julia version in juliapkg.json

[MilesCranmer]

The current behavior is to download the most recent Julia version that fits in the compat bounds. I was wondering if it would be possible to specify a "recommended" Julia version instead?

Julia 1.11 is going to release soon and it introduces a lot of performance regressions: https://discourse.julialang.org/t/julia-1-11-beta-high-latency/112819/8 including incompatibility with LoopVectorization.jl, so I am looking to bound my package to 1.10.

However, if a user installs 1.11 themselves, I would still like for them to be able to use 1.11. i.e., I don't want to make 1.10 a hard constraint. For non-Julia users, I would like to install the best possible Julia version for my package.

What do you think @cjdoris?

Cheers,
Miles

[cjdoris]

So you're thinking you'd like packages to be able to specify a preferred version of Julia, such as

{
  "julia": "1",
  "preferred_julia": "1 - 1.10",
}

?

Then presumably pyjuliapkg would respect as many of the preferred_julia bounds as possible, but it may not be possible to respect them all. And they would be totally ignored when using pre-existing installations.

Something like that?

It's a curious idea though TBH it seems quite unusual to me. The idea of the package manager not just installing the latest version of something when it could may be unintuitive. Is there any precedent in other package managers?

I'll also just point out that your package could emit a notice to direct the user to do juliapkg.require_julia("~1.10"). Not as graceful but could work ok.

[MilesCranmer]

I think your proposed syntax is good. And of course if the user has a pre-existing installation then that would be taken instead. The preferred Julia would exclusively be for pure-Python users who don't really mind what Julia they use; they just want a fast Python package.

It's a curious idea though TBH it seems quite unusual to me. The idea of the package manager not just installing the latest version of something when it could may be unintuitive. Is there any precedent in other package managers?

Since this would only be for Julia itself, not libraries, I'm not sure if a package manager is the right comparison. I think a closer comparison is the build dependencies of a given binary package. For example, when you download Julia as a binary, it is compiled against a particular LLVM version that the Julia devs choose (which they might have particular reasons for preferring, such as known issues with the most recent LLVM version). But if you compile Julia on your own machine, you have the option of compiling against your system LLVM which might be a different version.

I think it also works as a comparison to like numpy, for example. numpy's compiled backend that gets distributed to pure-Python users is built with a particular set of dependencies that the devs choose. (And most users don't care). But a power user can also compile from source with whatever dependencies they want. This is subject to some hard constraints, like GCC 8+.

So even if my package is compatible with the latest Julia, I would prefer to use a particular version due to some known issue with the latest version.

For example; that bug in Julia we saw on 1.10.1 and 1.10.2 which only affected Windows – I might wish to allow those Julia versions if the user already has Julia installed (because they might have a working version), but the user is installing Julia for the first time, I would avoid it.