The scope of Scala-cli

[romanowski]

In the #31 @sjrd and @przemek-pokrywka started a discussion about the scope of Scala CLI. Since back then there were no discussions set up I think should continue the discussion here.

I propose to discuss the scope of Scala CLI alongside the line of uses cases that Scala CLI should support and that should define the set of its features.

[przemek-pokrywka]

I think that it would be good to start with a brief summary of the main points from #31. Sorry if I misrepresent anything, please correct me, whenever I do so.

@sjrd proposed that

The scope of scala-cli stops where diverging choices of good options, or of no option at all, emerge based on varying use cases.

@romanowski hinted, that there is a commitment to support the following use cases:

• Education
• Scripting
• Prototyping
• Small, single module project (e.g. command-line tools, simple web services, etc.)

I, @przemek-pokrywka, tried to point at two general properties, that in my opinion are important for scala-cli to support:

• simplify Scala getting started experience
• play well with other members of the ecosystem: IDEs/editors, build tools in particular

Everybody agrees, that feature creep is something best to avoid.

@romanowski also noted, that the reverse situation (being under-featured) has its negative consequences too.

[przemek-pokrywka]

In the apparent (arguably narrow) conflict between the criteria proposed by @sjdr:

The scope of scala-cli stops where diverging choices of good options, or of no option at all, emerge based on varying use cases.

and between @romanowski's under-featured-ness remark, my stance is that it'd be better to err on the feature-bloat side.

It is because when a novice can do more things with simple tools, the excitement from getting things done makes them a natural evangelist of Scala in their environment and in their contacts network. It is very well known as Python's "batteries included" philosophy, which has served the Python community very well.

If we could also wisely pick the good defaults (like the famous Python's "There should be one-- and preferably only one --obvious way to do it." or like "The Rails Way" in Ruby on Rails framework), then we might also promote certain valuable patterns and approaches.

[kubukoz]

IMO the case of "small, single module projects" is really important - allow people to create a project, import it into the build, make changes and instantly run.

I think the current feature set plus publishing to Maven Central would be pretty much complete. Once we figure out how to solve configuration :)

[kubukoz]

If it's still possible to include files conditionally (e.g. "if JS", "if scala 3"), cross-compilation can probably be built on top of scala-cli if somebody wants it (as a separate tool or just a bash script in CI)

[przemek-pokrywka]

Yes, I think it would be safe to leave the cross-compilation to more sophisticated tools.

I imagined that the packaging support in scala-cli would let one create a simple reusable binary (Java bytecode) artifact, be it an app (fat jar / Coursier bootstrap jar) or a library. That would bring people a lot of power at a low cost (hopefully!).

[hohonuuli]

For me, scala-cli fills two holes in the Scala ecosystem: scripting and rapid prototyping against a particular version of Scala. There's already tools for building/publishing projects (sbt, mill, gradle, maven, etc). Do we really want or need another project build tool?

[przemek-pokrywka]

The beginners (large part of the target audience) will appreciate not having to learn and configure a build tool for the simplest cases (an app, a single module library), I believe.

Also, some modern languages ship with package managers (cargo in Rust for example) and having some basic capabilities in this area may be understandable (and even expected) by many, if scala cli is going to be positioned as something you begin your Scala adventure with. In my view, at least.

[hohonuuli]

BTW, See also https://tindzk.github.io/seed (which is basically a simple front end to bloop). It seems to provide the features being discussed here (very simple, TOML configuration, mutli-module, cross-platform, etc). It's probably worth looking at it for features to borrow for small projects.

[olafurpg]

I would love to see the current scope expanded to include multi-module builds and publishing. Beginner Scala users don’t necessarily have beginner needs, they could be expert programmers and their first Scala project could be deploying a JVM/JS web app to AWS. With publishing you can use Coursier for server deployment.

I’m hoping that scala-cli could become a gateway drug for people coming from other ecosystems like Rust or Go with simpler build tooling. I’m concerned the current limited scope is too limiting that scala-cli will struggle to find “product-market fit” (too niche use-case while still requiring significant development investment).

[romanowski]

Multimodule builds can be handled by something else like sbt or mill. One of our initial ideas to handle that is to turn Scala CLI into a command-line bsp client so people can use a limited set of Scala CLI commands on a codebase that is built using a tool that supports BSP. We dropped the idea, since we fear that support for such cases may be really misleading and error-prone.

To be clear, we do not plan to add support for multi-module builds in Scala CLI at any point. Scala CLI will remain single-module only.

However, I would love to have something with scala-cli like experience for multimodule builds. I've opened the dedicated discussion to identify the scope of such tool: #359

[olafurpg]

@romanowski what about publishing? That would at least unlock important use-cases like deploying a server or publishing a library.

[romanowski]

If you mean publishing to Maven Central then we are really close to committing to single module libraries support, where publishing is a key role.

We can package the code in various ways (docker image, assembly etc.) so what kind of publishing do you have in mind in terms of deploying servers?

[ckipp01]

If you mean publishing to Maven Central then we are really close to committing to single module libraries support, where publishing is a key role.

I'm actually hitting on this right now. Is being able to easily publish to Maven Central with scala-cli on the roadmap? I see this was mentioned way back #12 but unsure where you all landed on it.

[lwronski]

Publishing to Maven Central with scala-cli was added to the new roadmap 0.2/