[RFC] configuration file?

[bolinfest]

Currently, DotSlash does not support any sort of configuration file. The only thing that is really "configurable" is the location of the DotSlash cache folder, which defaults to the dotslash subfolder under the operating system's cache dir, but can be overridden via the DOTSLASH_CACHE environment variable.

An important advantage of this approach is that the "fast path" in the DotSlash execution flow (i.e., a cache hit):

https://dotslash-cli.com/docs/execution/

does not have to read any files other than the DotSlash file itself. Ideally, in adding support for a DotSlash config file, we would maintain this invariant. That is, the "fast path" should not have to read a config file, but the "slow path" is allowed to.

Config Options

Ideas we have kicked around in the past include:

• general curl configuration (which curl executable to use, proxy info, etc.)
• configuration for existing providers (for example, perhaps the URLs for the HTTP provider should be subject to an allowlist/blocklist)
• how to add custom providers (nothing is decided here yet: could be via shared libraries, though maybe also shelling out to another executable that takes a single JSON param)
• whether to enable UI to show any sort of "progress bar" when fetching an artifact
• garbage collection (which does not exist yet, but will likely need to be configurable when it does)

Location

We probably want some sort of "cascading set" of config files were one can override another, such as:

• .dotslashconfig in a parent folder / repo root?
• <CONFIG DIR>/dotslash
• /etc/dotslash/config

File Format

To avoid an undue increase on the size of the DotSlash binary, we should use "jsonrc" as the config file format.

[abesto]

Location

Hierarchical configuration like this is great. Usually I'd expect to also see beyond what you already have:

• ~/.dotslash (maybe this is what you meant with <CONFIG_DIR>)
• Overrides with ENV variables

I like https://rust-cli-recommendations.sunshowers.io/hierarchical-config.html for this.

[bolinfest]

By CONFIG_DIR I meant the thing that the linked Rust code could would return, which follows the XDG Base directory specification, so I guess I should have said XDG_CONFIG_HOME.

[alilleybrinker]

Is there is hierarchical configuration, it would be very useful to be able to ask the tool to display the config values it’s landed on, and ideally to report where each value is set. Can help with debugging when you expect the value to be one thing and it’s something else instead.