Mechanism to limit options and command based on the binary being used

[romanowski]

At this moment, it is clear that Scala CLI cannot become scala command and keep experimenting and adding new features. Both are the goals of this project so to achieve that we came up with a solution: ability to publish scala-cli as scala-cli (with all features) and as scala (with limited set of features and options).

We should investigate other option how to achieve same results (e.g. like using single command with --anvanced flag) and try to implement best solution.

The important thing to consider is that the solution should allow us to easily reuse / update current installation logic.

[prolativ]

Maybe scala-cli could have a command for switching between basic and advanced mode? That would be more convenient than having to pass a flag every time an advanced command is called. Maybe we could even allow being more precise in declaring what features should be available , e.g.

scala enable featureX
scala featureX .

But that would open a question of where the configuration of enabled features should be stored. In a user's home directory? In the root directory of a particular project? Somewhere else?

Going a step further the enable command could dynamically install some extensions to scala-cli, making it's core more lightweight. This would potentially also open a door for community-maintained extensions but I assume this would enforce a serious refactoring of scala-cli to make it open for plugins.

[julienrf]

I that would be a good thing to put in place (like the experimental flag in Scala 3).

However, I am not sure about the approach based on the name of the command. What about an --experimental command-line argument?

[tgodzik]

This seems to be already implemented.