Skip to content

Releases: VirtusLab/scala-cli

v0.2.0

22 Feb 07:20
e839a33
Compare
Choose a tag to compare

Require the --power option for restricted features by default

Until now, Scala CLI has been limiting some of its functionalities in its scala distribution.
Starting with v0.2.0, those limitation will be applied to all distributions, including scala-cli.

This was done in order to make the behaviour consistent with Scala CLI acting as the Scala runner.

Restricted features can be accessed by using the --power launcher flag. Do note that launcher flags have to be passed before the sub-command.

scala-cli --power package .

Alternatively, the power mode can be turned on globally by running:

scala-cli config power true 

Please note that this change may affect your existing scripts or workflows that rely on the limited commands from ScalaCLI (such as package, publish). You can still use those commands with power mode enabled.

When you try to use a limited command in restricted mode, you will now see a warning message with suggestions on how to enable this command:

$ scala-cli package Hello.scala
# This command is restricted and requires setting the `--power` option to be used.
# You can pass it explicitly or set it globally by running:
#    scala-cli config power true
$ scala-cli config power true
$ scala-cli package Hello.scala
# Wrote Hello, run it with
#   ./Hello

Added by @lwronski in #1835 and #1849

Allow executable Scala scripts without a file extension

As of this release Scala scripts without the *.sc file extension will be supported for execution when using the shebang command.

#!/usr/bin/env -S scala-cli shebang -S 3

println(args.size)
println(args.headOption)
chmod +x hello
./hello Hello World
#2
#Some(Hello)

Note that files with no extension are always run as scripts even though they may contain e.g. a valid .scala program.

Also, do note that this feature has only been added for shebang - the run sub-command (which is the default way of running inputs when a sub-command is not specified explicitly) will not support this.

Added by @MaciejG604 in #1802

Export Project configuration to Json

It is now possible to export configuration from Scala CLI project to Json format with the export sub-command.

scala-cli --power export --json .

It is currently exporting basic information about the project and includes, for example, the following fields:

  • ScalaVersion
  • Platform
  • Sources
  • Dependencies
  • Resolvers

Example of generated Json output:

{
  "scalaVersion": "3.2.2",
  "platform": "JVM",
  "scopes": {
    "main": {
      "sources": [
        "Hello.scala"
      ],
      "dependencies": [
        {
          "groupId": "com.lihaoyi",
          "artifactId": {
            "name": "pprint",
            "fullName": "pprint_3"
          },
          "version": "0.6.6"
        }
      ],
      ...
    }
  }
}

Added by @MaciejG604 in #1840

Rename using lib to using dep

To be more consistent with dependency command line options --dep, the dependency using directive is now passed by using dep.
Please note that we have kept the alias of the old directive (lib, libs) for backwards compatibility.

 //> using dep "org.scalameta::munit:0.7.29"

Renamed by @lwronski in #1827

Improved readability of help messages for commands

The help messages are now shorter and more concise, making it easier to quickly get an overview of the available options for a command.

To improve readability, some options and detailed messages are now only visible after showing the full help by passing --full-help.

Added by @Gedochao in #1872

Other breaking changes

Remove ammonite imports support

The support for $ivy and $dep ammonite imports has been removed.
To easily convert existing $ivy and $dep imports into the using dep directive in your sources, you can use the provided actionable diagnostic.

Screen Recording 2023-02-21 at 12 22 15

Removed by @MaciejG604 in #1787

Drop the metabrowse sub-command

With this release, support for Metabrowse has been removed from Scala CLI. This change was made in order to limit the number of features that we need to support, especially since the Metabrowse project is no longer being actively worked on.

Remove by @lwronski in #1867

Other changes

SIP-related changes

  • Add a warning for the -run option of the legacy scala runner, instead of failing by @Gedochao in #1801
  • Add warnings for the deprecated -Yscriptrunner legacy scala runner option instead of passing it to scalac by @Gedochao in #1804
  • Filter out restricted & experimental options from SIP mode help by @Gedochao in #1812
  • Warn in sip mode when using restricted command by @lwronski in #1862
  • Add more detail for sub-commands' help messages by @Gedochao in #1852
  • Fix printing not supported option in restricted mode by @lwronski in #1861

Fixes

  • Fix warning about using directives in multiple files when two java files are present by @MaciejG604 in #1796
  • Quit flag not suppresses compilation errors by @lwronski in #1792
  • Dont warn about target directives by @MaciejG604 in #1803
  • Fix - actionable actions not suggest update to previous version by @lwronski in #1813
  • Fix actionable action when uses latest sytanx version in lib by @lwronski in #1817
  • Prevent NPE from being thrown by the export sub-command if testFramework isn't defined by @Gedochao in #1814
  • Fix message checking in test by @MaciejG604 in #1847
  • blooprifle: add -XX:+IgnoreUnrecognizedVMOptions to hardCodedDefaultJavaOpts by @Flowdalic in #1845
  • Trim passwords obtained as command result by @MaciejG604 in #1871

Build and internal changes

Read more

v0.1.20

18 Jan 07:55
112c02a
Compare
Choose a tag to compare

Add support for Scala Toolkit

Scala CLI now has support for Scala Toolkit.

Scala Toolkit is an ongoing effort by Scala Center and VirtusLab to compose a set of approachable libraries to solve everyday problems.
It is currently in its pre-release phase and includes the following libraries:

  • MUnit for testing;
  • Sttp for HTTP client;
  • UPickle/UJson for reading, writing and operating on JSONs;
  • OS-Lib for operating on files and the operating system.

You can add it to your build from the command line with the --with-toolkit option.

scala-cli . --with-toolkit latest

There's also an appropriate using directive.

//> using toolkit "0.1.4"

Added by @lwronski in #1768

Scala CLI is built with Scala 3.2.2

We now rely on Scala 3.2.2 as the default internal Scala version used to build the project.

Added by @lwronski and @Gedochao in #1772

Removal of the about and doctor sub-commands

The about command has been removed, its features merged back to the version command.
As a result, the version command will now check if your locally installed Scala CLI is up-to-date.
It is possible to skip the check with the --offline option, or when printing raw CLI or default Scala
versions with --cli-version and --scala-version, respectively.

scala-cli version --offline                     
# Scala CLI version: 0.1.20
# Scala version (default): 3.2.2

Similarly, the doctor sub-command has been removed, with its past and previously planned functionalities to be delivered
in a more interactive manner in the future.

Added by @Gedochao in #1744

The Scala CLI aarch64/arm64 binary is now available via sdkman

You can now get the platform-appropriate Scala CLI binary on aarch64/arm64 architecture via sdkman.

Added by @mkurz in #1748

aarch64/arm64 artifact with the launcher script

The scala-cli.sh launcher script now correctly downloads the aarch64/arm64 artifact on the appropriate architecture.

Added by @mkurz in #1745

Run a .jar file as a regular input

JARs can now be run just like any other input, without the need of passing the -cp option.

scala-cli Hello.jar
# Hello

Added by @lwronski in #1738

Java properties without the need for --java-prop

The --java-prop option can be skipped when passing Java properties to Scala CLI now.

scala-cli Hello.scala -Dfoo=bar

Added by @lwronski in #1739

Docker packaging with using directives

It is now possible to configure packaging into a docker image via using directives.

//> using packaging.dockerFrom "openjdk:11"
//> using packaging.dockerImageTag "1.0.0"
//> using packaging.dockerImageRegistry "virtuslab"
//> using packaging.dockerImageRepository "scala-cli"

Added by @lwronski in #1753

Pass GraalVM args via a using directive

It is now possible to pass args to GraalVM via the following using directive:

//> using packaging.graalvmArgs "--no-fallback", "--enable-url-protocols=http,https"

Added by @lwronski in #1767

Other changes

SIP-related changes

  • Remove irrelevant options from version help message by @lwronski in #1737
  • Include launcher options in the help for the default and help sub-commands by @Gedochao in #1725
  • Remove suffix .aux from progName when installed by cs by @lwronski in #1736
  • Don't fail in case of connection errors in the version sub-command by @Gedochao in #1760
  • Set workspace dir to os.tmp.dir for virtual sources by @lwronski in #1771
  • Add support for deprecated Scala 2.13.x-specific scala runner options by @Gedochao in #1774
  • Add support for the -with-compiler runner option by @Gedochao in #1780

Fixes

Build and internal changes

Documentation updates

Updates & maintenance

New Contributors

Full Changelog: v0.1.19...v0.1.20

v0.1.19

19 Dec 13:39
effb570
Compare
Choose a tag to compare

What's Changed

The Linux aarch64 native launcher is here! (experimental)

We are happy to announce that there is a new dedicated launcher for the Linux Aarch64. You can find it here.

Added in #1703 by @lwronski

Fix workspace/reload for Intellij IDEA

Dependencies (and other configurations) from using directives should now always be picked up after a BSP project reload.

Screen.Recording.2022-12-13.at.13.34.17.mov

Fixed by @Gedochao in #1681.

shebang headers in Markdown

The shebang headers in scala code blocks inside a markdown input are always ignored.

# Scala with `shebang`
A sample code block with the `shebang` header.
```scala
#!/usr/bin/env -S scala-cli shebang
println("Hello world")
```

Added by @Gedochao in #1647

Export Scala compiler plugins to Mill projects

It is now possible to export scalac compiler plugins from a Scala CLI project to Mill with the export sub-command.

Added by @ carlosedp in #1626

Other changes

SIP Changes

  • Fix the order of help command groups for the default help by @Gedochao in #1697
  • Adjust SIP help output & ensure ScalaSipTests are run on Windows by @Gedochao in #1695
  • Add warnings for -save & -nosave legacy scala runner options instead of failing by @Gedochao in #1679

Fixes

Documentation updates

Build and internal changes

Updates & maintenance

New Contributors

Full Changelog: v0.1.18...v0.1.19

v0.1.18

30 Nov 11:44
66b915b
Compare
Choose a tag to compare

Filter tests with --test-only

It is now possible to filter test suites with the --test-only option.

//> using lib "org.scalameta::munit::1.0.0-M7"
package tests.only
class Tests extends munit.FunSuite {
  test("bar") {
    assert(2 + 2 == 5)
  }
  test("foo") {
    assert(2 + 3 == 5)
  }
  test("foo-again") {
    assert(2 + 3 == 5)
  }
}
package tests
class HelloTests extends munit.FunSuite {
  test("hello") {
    assert(2 + 2 == 4)
  }
}
scala-cli test BarTests.scala HelloTests.scala --test-only 'tests.only*' 
# tests.only.Tests:
# ==> X tests.only.Tests.bar  0.037s munit.FailException: ~/project/BarTests.scala:5 assertion failed
# 4:  test("bar") {
# 5:    assert(2 + 2 == 5)
# 6:  }
#     at munit.FunSuite.assert(FunSuite.scala:11)
#     at tests.only.Tests.$init$$$anonfun$1(BarTests.scala:5)
#     at tests.only.Tests.$init$$$anonfun$adapted$1(BarTests.scala:6)
#   + foo 0.004s
#   + foo-again 0.001s

Filtering particular tests by name requires passing args to the test framework.
For example, with munit:

scala-cli test BarTests.scala HelloTests.scala --test-only 'tests.only*'  -- '*foo*'
# tests.only.Tests:
#   + foo 0.032s
#   + foo-again 0.001s

Added by @lwronski in #1604

Accept authenticated proxy params via Scala CLI config

If you can only download artifacts through an authenticated proxy, it is now possible to configure it
with the config subcommand.

scala-cli config httpProxy.address https://proxy.company.com
scala-cli config httpProxy.user _encoded_user_
scala-cli config httpProxy.password _encoded_password_

Replace _encoded_user_ and _encoded_password_ by your actual user and password, following
the password option format. They should typically look like env:ENV_VAR_NAME, file:/path/to/file, or command:command to run.

Added by @alexarchambault in #1593

Support for running Markdown sources from zipped archives and gists

It is now possible to run .md sources inside a .zip archive.
Same as with directories, .md sources inside zipped archives are ignored by default, unless
the --enable-markdown option is passed.

scala-cli archive-with-markdown.zip --enable-markdown

This also enables running Markdown sources fom GitHub gists, as those are downloaded by Scala CLI as zipped archives.

scala-cli https://gist.github.com/Gedochao/6415211eeb8ca4d8d6db123f83f0f839 --enable-markdown

It is also possible to point Scala CLI to a .md file with a direct URL.

scala-cli https://gist.githubusercontent.com/Gedochao/6415211eeb8ca4d8d6db123f83f0f839/raw/4c5ce7593e19f1390555221e0d076f4b02f4b4fd/example.md

Added by @Gedochao in #1581

Support for running piped Markdown sources

Instead of passing paths to your Markdown sources, you can also pipe your code via standard input:

echo '# Example Snippet
```scala
println("Hello")
```' | scala-cli _.md

Added by @Gedochao in #1582

Support for running Markdown snippets

It is now possible to pass Markdown code as a snippet directly from the command line.

scala-cli run --markdown-snippet '# Markdown snippet
with a code block
```scala
println("Hello")
```'

Added by @Gedochao in #1583

Customize exported Mill project name

It is now possible to pass the desired name of your Mill project to the export sub-command
with the --project option.

scala-cli export . --mill -o mill-proj --project project-name

Added by @carlosedp in #1563

Export Scala compiler options to Mill projects

It is now possible to export scalac options from a Scala CLI project to Mill with the export sub-command.

Added by @lolgab in #1562

Other changes

Fixes

Documentation updates

Build and internal changes

Updates & maintenance

New Contributors

Full Changelog: v0.1.17...v0.1.18

v0.1.17

10 Nov 11:57
6e9117c
Compare
Choose a tag to compare

Enhancements

Set the default name for the project's workspace root file as project.scala.

There were multiple discussions about what the name should and it seems the winning vote was on project.scala instead of project.settings.scala.

To see how exactly is the root directory resolved, see this document.

Added in #1560 by @wleczny

SDKMAN and Homebrew support installation of Scala CLI for M1

To install Scala CLI via SDKMAN, run the following command from the command line:

sdk install scalacli

and to install Scala CLI via homebrew:

brew install Virtuslab/scala-cli/scala-cli

Added by @wleczny in #1505 and #1497

Specifying the --jvm option via using directives

The --jvm option can now be added via using directives, like

//> using jvm "adopt:11"

Added by @lwronski in #1539

Accept more scalac options without escaping

Scala CLI now accepts options such as -rewrite, -new-syntax, -old-syntax, -source:<target>, -indent and -no-indent, without requiring them to be escaped by -O.

Fixed by @Gedochao in #1501

Enable python support via using directives

The --python option can now be enabled via a using directive, like

//> using python

Added by @alexarchambault in #1492

Other changes

Work in Progress

Publish

Spark

Markdown

  • Add error handling for unclosed code blocks in Markdown inputs by @Gedochao in #1550

Fixes

Build and internal changes

Documentation / help updates

Updates / maintainance

New Contributors

Full Changelog: v0.1.16...v0.1.17

v0.1.16

14 Oct 09:56
7f5f2e8
Compare
Choose a tag to compare

This release consists mainly of updates, fixes, and various enhancements of existing features.

Enhancements

Specifying javac options via using directives

javac options can now be added via using directives, like

//> using javacOpt "source", "1.8", "target", "1.8"

Added by @lwronski in #1438

Pressing enter in watch mode proceeds to run / compile / test / … again

In watch mode (using the -w or --watch option), pressing Enter when Scala CLI is watching for changes makes it run again what it's supposed to be doing (compiling, running, running tests, or packaging, etc.) This is inspired by Mill's behaviour in watch mode, which supports the same feature.

Added by @alexarchambault in #1451

Installation via Scoop on Windows

Scala CLI can now be installed via Scoop on Windows, with a command such as

scoop install scala-cli

Added by @nightscape in #1416, thanks to him!

Actionable diagnostics in Metals

Scala CLI should now send text edit suggestions with some of its diagnostics, via BSP, so that editors
can suggest those edits to users. This should work in upcoming versions of Metals in particular.

Added by @lwronski in #1448

Other

Fixes

Fixes in Scala Native binaries caching

When running a sequence of commands such as

$ scala-cli run --native .
$ scala-cli package --native . -o my-app

Scala CLI should cache a Scala Native binary during the first command, so that the second command can just re-use it, rather than generating a binary again. This also fixes the re-use of compilation artifacts between both commands, so that the Scala CLI project isn't re-compiled during the second command either.

Fixed by @alexarchambault in #1406

Accept more scalac options without escaping

Scala CLI now accepts options such as -release, -encoding, -color, -feature, -deprecation and -nowarn, without requiring them to be escaped by -O. It also accepts --scalac-verbose, which is equivalent to -O -verbose (increases scalac verbosity). Lastly, it warns when -release and / or -target:<target> are inconsistent with --jvm.

Fixed by @Gedochao in #1413

Fix --java-option and --javac-option handling in package sub-command

--java-option and --javac-option should now be accepted and handled properly in the package sub-command.

Fixed by @lwronski in #1434

Fix wrong file name when publising Scala.js artifacts locally

The publish local sub-command used to publish Scala.js artifacts with a malformed suffix. This is now fixed.

Fixed by @lwronski in #1443

Fix spurious stack traces in the publish and publish local sub-commands

The publish and publish local commands could print spurious stack traces when run with non-default locales, using native Scala CLI binaries. This is now fixed.

Fixed by @romanowski in #1423

Make run --python --native work from Python virtualenv

Using both --native and --python in the run sub-command should work fine from Python virtualenv.

Fixed by @kiendang in #1399, thanks to him!

Documentation / help updates

Updates / maintainance

New Contributors

Full Changelog: v0.1.15...v0.1.16

v0.1.15

28 Sep 13:44
b2b52ea
Compare
Choose a tag to compare

The M1 native launcher is here! (experimental)

We are happy to announce that there is a new dedicated launcher for M1 users. You can find it here.

Please note that the package sub-command is unstable for this launcher.

Added in #1396 by @lwronski

--python option for repl sub-command (experimental)

Passing the --python option allows using ScalaPy with the repl sub-command:

▶ scala-cli --python
Welcome to Scala 3.2.0 (17.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                
scala> import me.shadaj.scalapy.py
                                                                                
scala> py.Dynamic.global.range(1, 4)
val res0: me.shadaj.scalapy.py.Dynamic = range(1, 4)

Added in #1336 by @alexarchambault

-d, -classpath and compile sub-command's --output options changes

To be backward compatible with the scala command, some changes have been made to the following options:

  • The compile sub-command's --output option has been renamed to --compilation-output. This option is now also available from the run and package sub-commands.
▶ scala-cli compile Hello.scala --compilation-output out
▶ scala-cli --main-class Hello -classpath out
Hello
  • The -d option is no longer an alias for --dependency, but for --compilation-output.
    • -O -d -O path/to/compilation/output now defaults to -d path/to/compilation/output.
▶ scala-cli compile Hello.scala -d out
▶ scala-cli --main-class Hello -classpath out
Hello
  • The old --classpath option has been renamed to --print-classpath.
    • --classpath, --class-path and -classpath options are now aliases for the --extra jars option.
    • -O -classpath -O path/to/classpath now defaults to --extra-jars path/to/classpath.
▶ scala-cli compile --print-classpath Hello.scala
# ~/Projects/debug-test/.scala-build/project_103be31561_103be31561-7a1ed8dde0/classes/main:~/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala3-library_3/3.2.0/scala3-library_3-3.2.0.jar:~/Library/Caches/ScalaCli/local-repo/v0.1.15/org.virtuslab.scala-cli/runner_3/0.1.15/jars/runner_3.jar:~/Library/Caches/Coursier/v1/https/repo1.maven.org/maven2/org/scala-lang/scala-library/2.13.8/scala-library-2.13.8.jar

Added in #1340 by @Gedochao

Make inputs optional when -classpath and --main-class are passed

The following changes have been made to improve backward compatibility with the scala command:

  • Passing the --main-class option along with -classpath to the default command now defaults to run instead of repl:
▶ scala-cli --main-class Hello -classpath out
Hello
  • If the run sub-command is passed explicitly, it's sufficient to have a main class on the classpath (inputs aren't necessary then):
▶ scala-cli compile Hello.scala -d out
▶ scala-cli run -classpath out 
Hello

Added in #1369 by @Gedochao

Debugging with the run and test sub-commands

It is now possible to debug code ran by run and test sub-commands:

▶ scala-cli Main.scala --debug
Listening for transport dt_socket at address: 5005
Hello

This addresses #1212

Added in #1389 by @wleczny

--platform option

This option can be used to choose the platform, which should be used to compile and run the application.

▶ scala-cli Main.scala --platform js
Hello

Note that --platform js is an alias for --js and --platform native is an alias for --native.

This addresses #1214

Added in #1347 by @wleczny

Other changes

Fixes

  • Ensure directories are created recursively when the package sub-command is called by @Gedochao in #1371
  • Fix calculation of Scala version and turn off the -release flag for 2.12.x < 2.12.5 by @Gedochao in #1377
  • Fix finding main classes in external jars by @Gedochao in #1380
  • Fix Js split style SmallModulesFor in pure JVM by @lwronski in #1394

Build and internal changes

Updates

Full Changelog: v0.1.14...v0.1.15

v0.1.14

13 Sep 15:21
540e7d5
Compare
Choose a tag to compare

Hotfix printing stacktraces from Scala CLI runner for Scala 3.x < 3.2.0

We fixed a nasty bug breaking any Scala CLI run using any Scala 3 version earlier than 3.2.0 on printing stacktraces.
Only Scala CLI 0.1.13 was affected.

$ scala-cli about
Scala CLI version: 0.1.13
Scala version (default): 3.2.0
$ scala-cli -S 3.1.3 -e 'throw Exception("Broken")'
Compiling project (Scala 3.1.3, JVM)
Compiled project (Scala 3.1.3, JVM)
Exception in thread "main" java.lang.NoSuchMethodError: 'long scala.runtime.LazyVals$.getOffsetStatic(java.lang.reflect.Field)'
        at scala.cli.runner.StackTracePrinter.<clinit>(StackTracePrinter.scala:101)
        at scala.cli.runner.StackTracePrinter$.coloredStackTraces(StackTracePrinter.scala:104)
        at scala.cli.runner.StackTracePrinter$.$lessinit$greater$default$4(StackTracePrinter.scala:11)
        at scala.cli.runner.Runner$.main(Runner.scala:18)
        at scala.cli.runner.Runner.main(Runner.scala)

Added in #1358 by @romanowski

Build and internal changes

Updates

Full Changelog: v0.1.13...v0.1.14

v0.1.13

12 Sep 17:59
2714573
Compare
Choose a tag to compare

Change the default sub-command to repl when no args are passed

We no longer default to the help sub-command when no arguments are passed. Starting with 0.1.13 running Scala CLI with no args will launch the repl.

$ scala-cli -S 3
Welcome to Scala 3.1.3 (17.0.3, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.

scala> 

When inputs are provided, Scala CLI defaults to the run sub-command, as before.

$ cat hello.sc
println("Hello World")
$ scala-cli hello.sc
Hello World

This change was added by @Gedochao in #1268

Marking the project's workspace root with the project.settings.scala file

Scala CLI now supports marking the workspace root directory with an optional configuration file: project.settings.scala. The workspace root determines where the .bsp and .scala-build directories will be saved (which mostly affects what path should be opened in your IDE to import the Scala CLI project through BSP).

The settings file is also the recommended input for your project's using directives. Otherwise, it functions similarly to other .scala sources.

$ cat project.settings.scala
//> using scala "2.13.4"
$ cat hello.sc
println(util.Properties.versionString)
$ scala-cli hello.sc .
version 2.13.4

To see how exactly is the root directory resolved, see this document

Added in #1260 by @wleczny

Scala CLI is now built with Scala 3.2.0

We now rely on Scala 3.2.0 as the default internal Scala version used to build the project.

This change was added by @lwronski in #1314

Add resources support for Scala Native

Scala CLI now allows embedding resources (by default) in a Scala Native binary with the --native flag.

$ cat resources/scala-native/foo.c 
int foo(int i) {
  return i + 42;
}
$ cat hello.scala 
//> using platform "native"
//> using resourceDir "resources"

import scalanative.unsafe.*

@extern
def foo(int: CInt): CInt = extern

@main def main =
  println(foo(3))
$ scala-cli hello.scala --native 
45

Added in #812 by @jchyb

Default to the run sub-command instead of repl when the -e, --execute-script, --execute-scala or --execute-java options are passed.

Even though we default to the repl sub-command when no arguments are passed to Scala CLI, an exception to that rule is when a snippet is passed with one of the following options: -e, --execute-script, --execute-scala or --execute-java. In that case, the passed snippets are treated as inputs to be executed and switch the default to the run sub-command.

$ scala-cli -e 'println("Hello")'
Hello

If you still want to pass a snippet to the repl, you can either pass the repl sub-command explicitly or use one of the following options, as before: --script-snippet, --scala-snippet or --java-snippet.

$ scala-cli --script-snippet 'println("Hello")'
Welcome to Scala 3.1.3 (17.0.2, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                                                                                             
scala> snippet_sc.main(Array.empty)
Hello

This change was introduced to make the -e option backwards compatible with the scala command.

Added in #1313 by @Gedochao

Work in progress

Support for Markdown (experimental)

Scala CLI can now accept .md inputs and run/compile a snippet of Scala code inside the markdown. Markdown sources are ignored by default unless passed explicitly as inputs. You can also enable including non-explicit .md inputs by passing the --enable-markdown option.

Plain scala snippets are treated similarly to .sc scripts which can be run by scala-cli:

$ cat Example.md
This is a simple example of an `.md` file with a Scala snippet.

```scala
val message = "Hello from Markdown"
println(message)
```
scala-cli Example.md
Hello from Markdown

See this document for more details about the experimental Markdown support.

Added in #1268 by @Gedochao

Add --python option for the run sub-command (experimental)

The run sub-command can now run ScalaPy when the --python option is passed.

$ cat helloscalapy.sc
import py.SeqConverters
val len = py.Dynamic.global.len(List(0, 2, 3).toPythonProxy)
println(s"Length is $len")
$ scala-cli helloscalapy.sc --python -S 2.13
Length is 3

Added in #1295 by @alexarchambault

Other changes

Documentation

Fixes

Build and internal changes

Updates

New Contributors

Read more

v0.1.12

23 Aug 08:48
7b81867
Compare
Choose a tag to compare

Add --spark, --spark-standalone and --hadoop options for the run sub-command (experimental)

The run sub-command can now run Spark jobs when the --spark option is passed.

$ scala-cli run --spark SparkJob.scala

Similarly, it's possible to run Hadoop jobs by passing the --hadoop option.

scala-cli run --hadoop HadoopJob.java

It's also possible to run Spark jobs without a Spark distribution by passing the --spark-standalone option.

$ scala-cli run --spark-standalone SparkJob.scala

Added in #1129 by alexarchambault

Add the default Scala version to the output of the version sub-command

The version sub-command now includes both the Scala CLI version and the default Scala version.

$ scala-cli --version
Scala CLI version 0.1.12
Default Scala version: 3.1.3
$ scala-cli -version
Scala CLI version 0.1.12
Default Scala version: 3.1.3
$ scala-cli version
Scala CLI version 0.1.12
Default Scala version: 3.1.3

You can also pass the --cli-version option to only get the Scala CLI version or the --scala-version option
to only get the default Scala version.

$ scala-cli version --cli-version
0.1.12
$ scala-cli version --scala-version
3.1.3

This is potentially a breaking change if your automation relies on the output of the version sub-command.

Added in #1262 by lwronski

Enable passing the scalafmt configuration with --scalafmt-conf and --scalafmt-conf-str

It is now possible to pass a custom location of the scalafmt configuration with the --scalafmt-conf option for the
fmt sub-command.

$ scala-cli fmt --scalafmt-conf path/to/the/conf/.scalafmt.conf

You can also pass the configuration straight from the terminal with --scalafmt-conf-str.

$ scala-cli fmt --scalafmt-conf-str  "version=3.5.5                                   
runner.dialect=scala213"

Added in #1227 by wleczny

Enable turning the --interactive mode on permanently

It is now possible to set the --interactive mode on by default, so that passing it explicitly isn't necessary.

The next time when you run a command with the --interactive option set to on, Scala CLI will suggest to turn it on
permanently.

This is recommended for environments where scala-cli is used by a human user only (and not by any automation).

$ scala-cli . --interactive
You have run the current scala-cli command with the --interactive mode turned on.
Would you like to leave it on permanently?
[0] Yes
[1] No
0
--interactive is now set permanently. All future scala-cli commands will run with the flag set to true.
If you want to turn this setting off at any point, just run `scala-cli config interactive false`.
Found several main classes. Which would you like to run?
[0] ScalaMainClass2
[1] ScalaMainClass1
[2] scripts.ScalaScript_sc

You can also configure it manually with the config sub-command, by setting the interactive property to true.

$ scala-cli config interactive true

Added in #1238 by Gedochao

Other changes

Work in progress

SIP-46-related

Documentation

Build and internal changes

Updates

New Contributors

Full Changelog: v0.1.11...v0.1.12