0

Just learned about scala-cli-- very cool-- and thinking about its possibilities for use in containers built off of scripts that non-devs could write: technically skilled people, currently writing elaborate and inscrutable bash scripts, but not up the traditional development workflow. The technical issues I have not been able to answer with regards to building containers including scala-cli are:

  1. How do I nail down a JVM and Scala version-- which must be pulled on container build-- so that there is no possibility scala-cli will check for and download the latest release, service pack, or hotfix? For example corretto:11 will actually download 11.0.19-- which I can also specify, but actually there are a couple of sub-version numbers after that which you only see during the download-- again, I can specify those, but how do I know there won't be a subsequent hotfix or patch released for that version? Having containers which start many times per day each check and install new JVMs and scala versions every time-- taking many times the runtime of the actual script runtime is something I must guarantee will not occur.

  2. Related to [1], can I disable checking for new scala and jvm versions completely?

  3. How can I set a default JVM version and scala version without specifying it on the command-line?

Love scala, and would love it if there were current answers to these questions, but if not, I'll probably try to steer them towards groovy, which looks a lot more mature in its scripting environment and predictable in terms of the questions above.

SourceSimian
  • 682
  • 4
  • 18
  • not sure if I understand your question. you are trying to build a container from a file that have a fixed version for the jvm and scala-cli. If you check [scala-setup.sh](https://virtuslab.github.io/scala-cli-packages/scala-setup.sh) it is just a bash script that says which scala version is going to download from [scala-cli - releases](https://github.com/VirtusLab/scala-cli/releases). You could use that script instead of download from that web – Gastón Schabas Jun 23 '23 at 17:18
  • @GastónSchabas Yes, you can control what version of scala is going to be downloaded initially by editing scala-setup.sh, but it does nothing to control scala-cli downloading different scala or jvm versions at a later time. – SourceSimian Jun 23 '23 at 17:39
  • I guess I understand a bit better now. You can fix the [scala-version](https://scala-cli.virtuslab.org/docs/cookbooks/scala-versions) using the parameter `--scala` and fix the [jvm](https://scala-cli.virtuslab.org/docs/cookbooks/scala-jvm/) using the `--jvm` parameter. Also you should check the [Scala supported versions](https://scala-cli.virtuslab.org/docs/reference/scala-versions/) for each `scala-cli` version. Is that enough? Not sure if I'm missing something – Gastón Schabas Jun 23 '23 at 17:49
  • Oh. I just read again and in [3] you asked if this can be done without passing a parameter in the CLI. The other option you have is to use directives in the file. You can write at the beginning of the file `//> using scala 2.13` and `//> using jvm "adopt:11"`. Not sure if that is ok in this case – Gastón Schabas Jun 23 '23 at 21:00
  • Thank you @GastónSchabasI am aware of the various ways to specify the scala version and the jvm version, but as I mentioned in the question they are untrustworthy-- as there is no guarantee they will not download some hotfixed version. – SourceSimian Jun 23 '23 at 22:30
  • Then pin the exact version and cache the downloaded version in docker image. – Mateusz Kubuszok Jun 23 '23 at 23:23
  • @MateuszKubuszok I don't think you can depend on that-- as I specified in my example, the JDK developers in question could always release a sub-version, unless you specifically read and know all of their policies you can't guarantee it won't happen-- or that they won't change their policy in the future. Personally, if scala-cli is going to be suitable for container use, it needs to be able to make hard guarantees. – SourceSimian Jun 24 '23 at 16:16
  • 1
    In your example you have `corretto:11`. You can specify `corretto:11.0.19.7.1`. If you "don't trust that this file might be overriden" you cannot also trust in any package manager, since in every image I can do "apt-get update" and override installed version. However if you run scala-cli in `Dockerfile` to install version - it will be installed globally and there is no reason for scala-cli's coursier to "hot fix it" on another run. I doubt it even has such option. I'd be surprised. By principle - Maven, Ivy2, tools builds on them - don't query artifactories if there is value in local repo. – Mateusz Kubuszok Jun 24 '23 at 16:32
  • Like @MateuszKubuszok said - just pin a precise version. – Łukasz Biały Jun 24 '23 at 16:41
  • Again though— I can specify corretto:11.0.19.7.1 and have it download in the docker image no problem… but what happens when amazon releases corretto:11.0.19.7.1.1? All of a sudden my containers which have been starting and running quickly now all download the updated version on each run. I posted this question hoping that there was a way to get a hard guarantee from scala-cli that this would not happen, but if doesn’t look lime there is. – SourceSimian Jun 25 '23 at 23:07

0 Answers0