Should we drop Ammonite script support?

[tgodzik]

We currently have two ways of running any scripts and that might be confusing for users and I don't believe we are able to provide the same level of support for both.

Because of that I am thinking of dropping Ammonite support and focus on the Scala CLI one.

1. Is anyone adamantly against this?
2. How many people are actually using metals for ammonite? (please react with any +1)
3. Would people using Ammonite miss any feature in Scala CLI?

Please let us know what you think about this!

[alvinj]

My two cents: I have used a few Ammonite scripts, and would have no problem switching them to Scala CLI. I know that when my resources are limited I think, “Every hour I spend supporting [something like Ammonite scripts] I could be working on [new features that deliver value].” So I’m all for focusing on only Scala CLI.

[andrewbaxter]

I'm not a core user, I've been exploring Ammonite for my needs and haven't heard of Scala CLI before.

Ammonite has bundled libraries which I believe mean I should be able to use it on offline systems, and without needing to install anything beforehand aside from Ammonite. Scala CLI doesn't have anything bundled AFAICT, and its goal to be a lightweight tool seems opposed to that.

I'm not sure how many people share my use case. That said, at least right now it doesn't seem like Ammonite has any particular features for making working offline nicer either.

(I just stumbled by here while wondering why Metals is complaining about @main in my Ammonite script)

[tgodzik]

Ammonite support for scripts is really not that different from Scala CLI, there is a bunch of features, but those are mostly power user ones, which why I am wondering whether to drop it. Scala CLI does have an offline mode which we can make sure works good with the default way of installing Scala (but I already see everything is being discussed in the Scala CLI repo)

[andrewbaxter]

The difference I wanted to highlight is that with Ammonite,

#!/usr/bin/env amm
import ujson.Js
println(ujson.write(1))

makes no network requests, so the script can be run on internet-less systems with ammonite pre-installed with no additional work, the same way a similar script could written in Python. It includes http, json, subprocess support, and command line parsing which I think constitutes 99% of the batteries I use for scripts in Python.

The equivalent (AFAICT?) in scala-cli

#!/usr/bin/env -S scala-cli shebang --scala-version 2.13
println(os.pwd)

fails (not found: value os). --toolbox default tries to download the toolbox. Neither Scala nor scala-cli bundle the toolbox code (again AFAICT), so this is to be expected.

Yeah sorry, I did ask about it in scala-cli too here: VirtusLab/scala-cli#3014 - but it wasn't clear from the last reply whether this use case might be supported by the project. I'd have no hesitation to move to scala-cli if this could be supported. The Ammonite documentation on bundled libraries is minimal and there are requests to move the opposite direction, so my reliance on Ammonite's packaging may be on shaky ground in the first place.

[tgodzik]

Och, I wasn't actually aware that the libraries were bundles, it would probably be good to allow the same for toolkit and make sure that toolkit contains everything that would be needed. That's a good suggestion.

[andrewbaxter]

Just to be very clear, I'm not a core user and my use case might be rare, I'm not sure... just wanted to note it in case it was relevant to the discussion. It seems like their are two parties, one who want clearer isolation, fewer included deps, and then... me (not to say there aren't times when I want total control over the environment).

[tgodzik]

That's exactly why I raised this discussion!