Default Registries / Local Configuration

[asmello]

Most package managers like Cargo, PIP etc. have a built-in registry that they use to source packages from, so that most users don't need to manually specify which one they want. This is not possible for Buffrs (yet!) because we don't have a public registry available. However, it's highly inconvenient to manually specify the registry every time we invoke a command (or every time we specify a dependency).

Directionally, we should probably have a hierarchy of configurations for determining which registry to use that looks like this:

1. Use manually specified registry from command arguments
2. Use manually specified registry from manifest
3. Use user default registry from global user configuration
4. Use system default registry from global system configuration (maybe?)
5. Use built-in registry that ships with the CLI (not possible yet)

We'd apply the first config that is set in that list.

I'm opening up this thread for us to discuss the specifics of how that should look like. How does configuration get set? Where does it get stored?

My first proposal is the following:

CLI support

We introduce a config command with the following subcommands:

• get <key> — will print the current value for the given configuration entry. I think it'd be nice to have a flag to show where the configuration is being defined, too.
• set <key> <value> — will set the specified value for the given configuration entry (validating the type), to user configuration by default. Unsure if we should have a flag to set it globally as system-wide configuration (thoughts?).
• list — lists the configuration options that Buffrs supports. Optionally, via a flag, will also show current values (is this a good idea?).

The first configuration setting that we'd support is registry.default, which is simply a URL for a registry that gets used if not manually specified via a CLI argument or manifest.

Note that keys follow the proposed structure of the TOML file we'd store the configuration in. This should help make things predictable and intuitive. Unsure how we'd deal with complex types like arrays, but we can cross that bridge when we come to it later.

Changes to existing commands

The only planned change is that passing --registry explicitly will be made optional for several commands: add, login, logout and publish.

Manifest changes

No changes planned. We could perhaps add an optional registry section that could allow for overriding the default registry at the package level, but I'm not convinced this is worth the complexity. Open to differing opinions.

User-level configuration

I'm thinking we continue the pattern of using TOML files and just create a $HOME/.buffrs/config.toml file to store user-level configuration. It'd be dead simple to start with:

version = 1

[registry]
default = "https://..."

Including the version should allow us to deal with migrations across breaking changes to the specification. Additive changes should be non-breaking, unless mandatory fields are added (I don't think that should happen though as sensible built-in defaults are probably a better alternative).

System-level configuration

Unsure if we want this for the V0. My bias is to not do it, but open to thoughts. It should probably be a TOML file following the same structure as the user config.

[mara-schulke]

We should think about how this affects publishing buffrs packages, as we need to make the manifest "absolute" as in: we can not leave out the registry field on dependencies at publish time, as we would loose the information on which registry the dependencies are located in

[asmello]

Would it be a reasonable assumption to make that if otherwise unspecified in the manifest that other packages can be found in the same registry?

Maybe this is a valid reason to permit explicitly specifying a package-level registry in the manifest as well.