scala-steward

scala-steward copied to clipboard

Scala CLI has a dependency-update command to update //> using lib directives. I would like Scala Steward to be able to keep these up-to-date as well.

Thank you for maintaining Scala Steward!

Scala Steward expect Scala project to be a Git-managed repo and to have one of sbt/mill/maven. Since I do not use Scala CLI, several questions come in.

• Is typical Scala CLI files managed by Git?
• What is a typical convention of directory structure for Scala CLI files (.scala)?
• What is "build tool" for Scala CLI or build tool not used?
• What "directives" do you imagine?

Thanks @exoego. Depending on the product vision and architecture of Scala Steward it might be interesting to add Scala CLI support as a feature next to the current sbt/Maven/Mill support.

Note I’m still figuring out best practices for Scala CLI myself in an exploratory project (@sander/docpkg).

For context: Scala CLI was highlighted by Martin Odersky in last year’s ScalaCon opening keynote as an easier way to work with Scala code and it is now part of the default installation recommended on the Scala website. It is advertised as being suitable for single-module projects. In my experience so far this seems true.

Scala Steward expect Scala project to be a Git-managed repo and to have one of sbt/mill/maven. Since I do not use Scala CLI, several questions come in.

• Is typical Scala CLI files managed by Git?

Scala CLI does not seem to care, but the docs imply using a version control repository indeed. Using Git makes sense, especially for Scala CLI users who wish to apply Scala Steward.

• What is a typical convention of directory structure for Scala CLI files (.scala)?

I cannot find dedicated recommendations yet, but what I’ve found works well is one project folder with .scala source files (possibly in subfolders), and/or a folder with .sc script files. Any of these can contain dependency specifications.

Upon invoking scala-cli, the file/folder needs to be specified, e.g. my-script.sc or ./ or src/ or scripts/. I suggest that any Scala Steward configuration for a project either specifies which files/folders should be checked, or assumes that any .sc and .scala file should be watched.

Some of the examples such as Setup multiple Scala CLI projects in IDEA IntelliJ as separate modules seem to support this.

In one private project I am exploring a combination of sbt for the main project and Scala CLI for related scripts, as per Setup a Scala CLI project in IntelliJ alongside your existing SBT project

• What is "build tool" for Scala CLI or build tool not used?

There is no additional build tool.

As mentioned, dependency-update or the underlying library code should be able to provide much of the data needed for Scala Steward to find dependencies and potential updates.

• What "directives" do you imagine?

Scala CLI currently recommends one way to specify dependencies: the using lib directive. For example, the top of a .scala or .sc file could contain:

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

Thanks for the detail.

I've marked this feature as "help wanted" since I (one of maintainers) am focusing on other projects recently and may not have enough energy on this feature in the coming months. I guess other maintainers have the same situation too.

But I welcome contribution to this feature and will give help.

FYI: https://github.com/scala-steward-org/scala-steward/pull/2816 would be able to update versions also in using lib directives as can be seen here.

As I understand it, updating dependencies in using lib directives is very similar to the request of updating dependencies in $ivy imports in Ammonite scripts (#696). In both situations there is no tool for Scala Steward to call in order to retrieve the dependencies of a project (as opposed to sbt, Mill, and Maven projects) but Scala Steward would have to scan source files itself to gather all dependencies. There is also no easy way to know if a project uses Scala CLI or Ammonite scripts. For sbt for example, we can just check if build.sbt exists and then know if sbt is used or not.

Implementation-wise, Scala Steward would only need to have a new BuildToolAlg implementation for Scala CLI and Ammonite scripts that scans sources for using lib directives and $ivy imports. If we would have such a BuildToolAlg, at least two questions arise:

1. Should we always scan *.scala and *.sc files for dependencies or only if it is enabled via the configuration?
2. Should we only scan files in the build root or should the we scan in all directories recursively?

Maybe there is an easier way to support scala-cli projects than sketched above. scala-cli has the export command which exports the scala-cli project to sbt or Mill. We could use that and then delegate to SbtAlg or MillAlg to retrieve dependencies and resolvers from the exported build.

#2933 is WIP PR for the idea mentioned in https://github.com/scala-steward-org/scala-steward/issues/2686#issuecomment-1386629936.