Inject latest scala version when run Scala Script for the first time without version directive

[windymelt]

Hi, every time I write Scala Script, I check out for latest Scala version and write it to the Scala Script.

//> using scala /* few minutes to search "scala latest version" */ 3.6.3

println("Finally I can write Scala Script!")

If scala-cli can detect and inject latest Scala version, I feel no pain for this.

println("Hello, somehow latest Scala!")

% scala-cli code.scala.sc
// inject latest Scala version into code.scala.sc
Hello, somehow latest Scala!
% cat code.scala.sc
//> using scala 3.6.3

println("Hello, somehow latest Scala!")

Any ideas for this?

[SethTisue]

few minutes to search "scala latest version"

fwiw, I usually just run Scala-CLI itself to get this; it starts a REPL and the version number is in the banner:

% scala
Welcome to Scala 3.6.3 (17.0.14, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                                    
scala>  

but it's an interesting idea that scala-cli could offer a way fill in the version, perhaps via scala fix?

[Gedochao]

@windymelt if you want the latest version, why not use the dynamic/vague directive argument?

//> using scala 3

Rather than passing the full version (which you are not sure what that is), you can just pass 3 as the argument.
Of course, this also depends on the definition of the words latest version, as that will actually cap at the default Scala version of your Scala CLI launcher (which is by design, we do not want a way to use the latest version upstream).

but it's an interesting idea that scala-cli could offer a way fill in the version, perhaps via scala fix?

@SethTisue it'd be a valid feature request. I guess we could have a rule to add the using directive with the version if it is not specified. Or to change existing vague directives, like //> using scala 3 in the user's code. Feel free to raise an issue, if it sounds useful.

[sjrd]

It's what I've been suggesting for years. You want the latest version at the time you create your script. But afterwards you want that version to be persisted (fully, not just 3). This way, your scripts will survive new releases of Scala, and even upgrades of scala-cli.

Today, the using scala 3 is much better than it was. It will survive changes on the Internet when a new Scala 3 release is published. But it can still break when you upgrade scala-cli.

I don't understand how I failed to convey this need over the years. Even the Python ecosystem has understood this now with uv. When you do uv init you get the latest Python version at the time of init, but then the full version is persisted in .python-version. Upgrading uv will never break your existing projects.

[tgodzik]

Though in case of python I guess this is because there is no other way of pining the language version. Here we can just use specific version always. We could even report a hint diagnostic as with other libraries or ask scala steward to bump scala version.

I do understand the problem here, but I really don't think we should have yet another way of defining Scala version in a separate file. Because that's what it would be, not just a pin, but a separate configuration option.

If you think of it in terms of normal dependencies we could have the same, use org.example:module:latest and pin that in some kind of a lock file, but that would make it two ways of defining library versions.

[sjrd]

No, this is not what anyone is suggesting. The suggestion is to edit the using line to write the full version there. (Or insert it if there isn't one yet.) So it really is exactly the same mechanism we already have. Just with a convenient (and IMO should be default) way to say "insert the full version of what Scala is today, do that tomorrow it stays there".

We don't need lock files in the Maven ecosystem because transitive dependencies are deterministic and time-independent.

The only reason "lock files" have been in our vocabulary since the arrival of scala-cli is because the latter encourages time-dependent versions in the using config. I told everyone it was a mistake then; I keep saying it now; and I will keep saying it every time this kind of issue comes up, because it is still time to go back to the sane, deterministic, time-independent defaults that all the other ecosystems have been envious of for decades.

[Gedochao]

No, this is not what anyone is suggesting. The suggestion is to edit the using line to write the full version there. (Or insert it if there isn't one yet.) So it really is exactly the same mechanism we already have. Just with a convenient (and IMO should be default) way to say "insert the full version of what Scala is today, do that tomorrow it stays there".

That'd be a valid feature request for the fix sub-command (side-discussion, whether that should be built-in or scalafix: #3499).
If by "default", you mean that it should happen on run, then I think that's a big no-no - plain running of scripts should not modify sources. it could be a default fix rule, though.
Feel free to raise a ticket.

The only reason "lock files" have been in our vocabulary since the arrival of scala-cli is because the latter encourages time-dependent versions in the using config. I told everyone it was a mistake then; I keep saying it now; and I will keep saying it every time this kind of issue comes up, because it is still time to go back to the sane, deterministic, time-independent defaults that all the other ecosystems have been envious of for decades.

Well.. we could, theoretically, deprecate time-dependent version values, like 3, 3.lts and such. Although that'd be a rather big change, so it would have to be widely requested. TBH I'm myself rather fond of the current status quo, as those are convenient in their own way. Nobody stops anyone from using full versions, to make their scripts fully independent - and a fix rule would automate it, if there's desire for it to happen automatically.

[SethTisue]

a fix would be sufficient IMO