Reduce duplication between using directives and command-line flags

[lrytz]

Certain command-line flags are available as using directives, e.g., --dependency and //> using lib. Some options are only avaialble as command-line flags.

It might make sense to introduce a special using directive that allows specifying any scala-cli command line flag. For example, //> using cliOpt --dep org.scalatest::scalatest:3.2.10. This just shows how it would work, I'm not suggesting to remove using lib.

That would make all options available as directives, and it would allow reducing directives to a minimum (random example: the jsModuleSplitStyleStr directive will probably be very rarely used).

Related to #1337.

[bjornregnell]

I think this is a very good proposal at it provides a future proof scheme of evolving the using-directives and command line flags together.

[julienrf]

Do I understand well that this would add another way to configure a project?

scala-cli --dependency foo::bar:42

//> using lib "foo::bar:42"

//> using option "--dependency foo::bar:42"

I appreciate the fact that this would provide more consistency: the same syntax can be used in command-line arguments and in file comments (see 1. and 3).

However, it also means that within file comments there would be two means of configuration (using lib and using option --dependency, in this example), which I think is not a good thing.

I don’t think we should drop 2. and support only 3. because that would not be ergonomic, as you noted.

However, I wonder if it would be possible (and a satisfactory solution) to systematically support both command-line arguments and magic comments for all the possible configuration options, and always use the same names. In the example, I think the problem is that we use --dependency for command-line arguments but lib in magic comments. Instead, we should use the same name, dependency, everywhere:

scala-cli --dependency foo::bar:42

//> using dependency "foo::bar:42"

[lrytz]

My proposal is to have all 1., 2. and 3., but reduce 2. to the most important options (i.e., remove some of the esoteric ones that currently exist).

I think there's always going to be yet another command line flag that has no using directive, and someone is going to need it.

The alternative of systematically ensuring every command line flag has a matching and same-named using directive is also fine with me.

[bjornregnell]

I think //> using lib is nice, short and, by now, established, so there is, at least initially, a cost of starting to require to write the longer //> using dependency. But I see your consistency point. But we can allow both for backward compatibility.