Global configuration

[romanowski]

Should Scala CLI allow to define a global configuration?

On the one side, for ad-hoc scripting, it would be really beneficial if a blank script comes with predefined dependencies etc.

On the other side, this will be a bit problematic for reproducibility.

We can find a middle ground, but first, we need to know if this is something that the community really need.

[mpilquist]

👍 for not supporting global configuration and perhaps instead supporting a flag to load such shared config. Keep it as simple as possible with no environmental configuration.
👎 on predefined dependencies, assuming goal of scala-cli is to eventually replace the "scala" script.

[kubukoz]

I would rather suggest a way to import shared options from a URL (gist?) or a path on disk.

This would allow a form of global configuration by wrapping the standard scala-cli binary with a script that adds the right --include ~/.scala-cli/global/plugins.scala or whatnot.

👍 for keeping reproducibility - assuming the user has access to the explicitly referenced "shared options" file, they should get the same settings.

[przemek-pokrywka]

What do you think, would global configuration be of help for secrets, like credentials to company-internal repositories? Or would it be better to keep such things as environment variables or company-internal wrappers to scala-cli, which would add the required secrets on the fly?

Related to #300

[ches]

Regarding repositories and their credentials:

I set COURSIER_REPOSITORIES to use a company repo with cs and that works with scala-cli already. But to @ckipp01's point in #300, it's not obvious for a Scala CLI user who is not well-acquainted with Coursier to discover, and for the reproducibility points here it's not good either. I think the using repository directive should be the recommendation. It's not onerous to me if I need to declare the company one explicitly in every project, and a wrapper workflow or using the Coursier var remain options for someone/an org who feels differently.

For credentials, again in the spirit of #300, it's already a bit of a headache that sbt projects will often refer to files in its credentials text format, Coursier has an env var or properties file, etc.—let's not add fuel to the fire with another place to do that, and cleartext files are an antiquated solution anyway. I have an idea to suggest but I'll elaborate it on #300 to try to keep on the broader topic here.

Aside from repo credentials, there is only one thing I've found in my Scala CLI usage so far that I might like to set not locally to projects: ad hoc REPL session defaults. It's very handy to launch scala-cli repl outside the context of any project just to check something / help someone, often with a particular --jvm, --scala, or --dep version. But it'd be nice to set a few things like --amm --scala <my company's most common binary version> as user-level defaults if I wish to. (User-level configuration would not be applied if a path is given like scala-cli repl myscript.scala, though explicit flags like scala-cli repl --scala 3 myscript.scala should take precedence even over directives in the file, in case I want to try out a change ad hoc).

👎🏼 on global configuration for anything that hinders project reproducibility implicitly

👍🏼 for some way to set user preference things globally. But only REPL comes to mind so far, and to me it's a low priority nice-to-have.

Perhaps another use case that could apply is if there is ever a scala-cli init sort of command that might generate a file with some directives pre-filled.

[lilyevsky]

I also set COURSIER_REPOSITORIES environment variable to use company Nexus repo with scala-cli, and it was working with version 0.1.5.
Now I upgraded scala-cli to 0.1.14 and it is not working anymore.
Could anybody tell me what changed and how do I set the repositories now?
I tried --repositories option in command line, it does not help, coursier is still trying to fetch artifacts from central repo.

[lilyevsky]

I found a solution: coursier mirrors, see https://scalameta.org/metals/docs/troubleshooting/proxy/ . I tested and it works.
Why isn't it documented anywhere? I searched scala-cli docs and coursier docs, couldn't find it there. What hlped me in the search was that accidentally I came across this post: #1109 , which mentions mirrors.