Design: should commands such as compile and run require an argument?

[SethTisue]

Currently

• I can't scala-cli compile, I must scala-cli compile .
• I can't scala-cli run, I must scala-scli run .

I can't tell you how many times I have typed these commands, and it errors, and I sigh and supply the .. Countless times.

Ironically, it's more ceremony than sbt. I can sbt compile or sbt run 🔥

This came up today in discussion with @Kordyjan, @sjrd, and @dwijnand.

Paweł thought the current behavior might be for consistency with scala-cli repl, aka scala-cli because it defaults to opening a REPL, aka scala because it will soon be the default runner.

Is it too surprising that if I just scala, it would compile files in the current directory and put them in the classpath?

Even if we decide that's okay, do we need a way to definitely only just open a REPL? scala-cli repl --standalone or something...?

[prolativ]

Related: #1686.

The difference to sbt run is that in sbt it seems easier to tell whether your cwd is actually the intended root of a project or not because of the presence of a *.sbt (typically build.sbt) file.
Personally I sometimes create multiple small scala-cli projects in the same root directory and work on them with scala-cli compile foo, scala-cli run bar etc. If I type just scala-cli compile I will be warned about forgetting to specify the sources. If . was taken implicitly instead, I might be getting some strange errors, especially if I had some clashes in naming because these projects were supposed to be independent so I didn't care about proper nesting of packages. Or (what's even worse, although less probable) the code could compile but with different semantics (e.g. because some given instance was taken from another module).

[SethTisue]

to tell whether your cwd is actually the intended root of a project

Perhaps the presence of at least one .scala file in cwd would be sufficient?

Personally I sometimes create multiple small scala-cli projects in the same root directory

That seems like a totally valid use case — but one to be accommodated, rather than one that should drive default behaviors. The standard use case — for newcomers, but also even for many experienced users — is a single directory with some .scala files in it.

[prolativ]

Personally I don't really feel convinced. As the issue I linked shows, it's not always that clear what should be considered the default and the more we rely on some guesses from a tool, the bigger is the chance that users will be surprised with the inferred behaviour. For me writing this extra . has never been a problem. It doesn't really make much more typing but it makes things explicit. It also seems consistent to me that every scala-cli command requires passing sources as an argument (with some exceptions like repl or version but in these cases this simply means no sources).

[bjornregnell]

I used scala-cli for the fall semester with 190+ students and I often saw students trying to run scala-cli without the dot. If we think there must be an arg and a user does not provide it at least scala-cli could ask the user interactively if it wants to run it in this dir and then remember that choice.

[Gedochao]

We had a discussion about this in the Scala CLI team and we decided against it.

One concern is consistency. Taking the current working directory (or .) implicitly as inputs would have to be applied across all of the commands of Scala CLI, if we went that direction.
That in turn would force us to include the repl sub-command.
That's all the more of a problem, as repl is the default sub-command.
We don't want people to accidentally run everything they have in their home directory in the repl after just running scala-cli.

It's easier to decide to do things this way in tools like SBT, where the project structure is required to be defined in a configuration file. While Scala CLI does have a convention for the project.scala file, it is entirely optional, and also just that - a convention, and not a requirement for running a project.

TL;DR it seems like we want to stick to requiring the . argument.

[SethTisue]

Okay, thanks for considering it and for summarizing here. You could always change your minds later ;-)