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]

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!

[urbanchr]

A feature that I am missing in scala-cli is the import of other scala files. Things like

import $file.some_file

is not very well supported by scala-cli. The same with dependencies of libraries. By writing

//> using dep org.scala-lang.modules::scala-parallel-collections:1.0.4

one would hope scala-cli includes the dependency to this library in a script, but instead you need to give the dependency explicitly on the commandline again (I think a similar point was recently made on scala-users and maybe in the future scala-cli acquires this feature). Scala-cli is also not yet there when it comes to "using-clauses" distributed over multiple files. Because of these limitations, I have not yet made the switch from amm to scala/scala-cli.

[tgodzik]

//> using dep org.scala-lang.modules::scala-parallel-collections:1.0.4

This should include it in the script, but if you run the script explicitly we will not include any other files. You need to always provide the full input files. Best in that case is just to do scala-cli run .

You can also import files via a directive https://scala-cli.virtuslab.org/docs/commands/run#define-source-files-in-using-directives

[tgodzik]

I checked the current state for Ammonite (I mostly use Scala CLI) and it doesn't seem to work. Since we don't really have resources to work on fixing it, I am planning to remove Ammonite support soon.

[tgodzik]

#7309