Configuration file(s)

[lann]

As we're thinking about specific configuration files (ref #2), I'd like to step back and consider all of the possible kinds of config we might need in the medium-term so that we can design a cohesive config story. Let's try to be comprehensive here: some of these things might not end up going in any config file defined in this repo but could still be useful in understanding the big picture.

Seeding the list:

• Namespace to registry mappings
  • Per-workspace vs (user-)global
  • Default/fallback registry
• Per-registry config
  • Protocol-specific config
  • Credentials (distinct from generic config due to sensitivity)
• Dependencies
  • cargo-component's [package.metadata.component.dependencies]
  • Dependency resolution overrides?
• Package metadata
  • RegistryMetadata

[lukewagner]

I'm aware of 3 places where I think I'd like to put different kinds of config:

1. In a global location to serve as overridable defaults for the next 2 use cases. Here, the configuration I'd expect is:
   A. The domain of a registry I'd like to use by default to resolve registry names. I think even without setting this, tools developed by the BA should default to bytecodealliance.org, so this config is mostly for when you want a domain other than bytecodealliance.org.
   B. A mapping from namespace to domain that is consulted first before A, thereby allowing me to easily use multiple registries defining multiple namespaces.
   C. For both of the above, the "Per-registry config" Lann mentions.
2. When I'm building a component, in my native language build-config file that is already used by my language's top-level build command (so Cargo.toml for cargo component, package.json for jco componentize, etc). Here, the configuration I'd expect is:
   A. Overrides of the global config mentioned in (1), scoped to this repo.
   B. The "Dependencies" and "Package metadata" that Lann mentioned.
   C. The name of the world I'm targeting, if it's already defined/published (e.g., wasi:http/[email protected]).
   D. If the world I want to target is custom, a local relative file name of a locally-authored .wit file anywhere in my source directory which can refer to published interfaces (e.g., via include wasi:cli/[email protected]).
3. When I'm authoring a WIT package (for a WASI proposal or for my host's custom API), a "WIT.toml" that acts as the build-config for the WIT package I'm intending to publish. Here, the configuration I'd expect is:
   A. Overrides of the global config mentioned in (1), scoped to this repo.
   B. Version information that I could put in .wit files (the WIT text format allows it), but I'm choosing to factor out, following normal source code practices, since WIT is the "source code" I'm developing here.

I think it's important to distinguish case 3, where the developer wants to directly interact with a WIT CLI (as their top-level build tool), from case 2 where we want to factor out common logic from all the different top-level build tools. I think what this suggests is that the latter takes care of consulting the case 1 global config, factoring out the logic of looking in home directories or env vars or whatever the best practice is these days, but provides command-line options for overriding these defaults, allowing the various top-level build commands to supply these overrides when present in their various build-config files (from case 2).

[calvinrp]

This is probably the answer. But maybe both package metadata and registry config are the things that need to be in there. Maybe naming wasm-pkg-config or wasm-pkg.

[lann]

It isn't clear to me that package and registry config should live in the same file. Registry config seems to be mostly a consumer concern while package config is a publisher concern. As reference, other tools that keep these separate:

• cargo: Cargo.toml vs .cargo/config.toml
• npm: package.json vs .npmrc
• python: setup.py vs .pypirc

[calvinrp]

Either in one or split into two files, just makes sense to think about configuring both the package metadata as well as registry configuration.

[lann]

At this point the design I have vaguely in mind is:

• One standard (set of) config file(s) for registry config, something like ~/.config/wasm-pkg/config.toml, <project>/.wasm-pkg/config.toml, etc.
• Standardized schema for package metadata, but with tool-specific details: wit.toml, Cargo.toml ([package.metadata.component]), package.json

[calvinrp]

That sounds great to me

[lann]

re: global registry config, see for reference this example of wasm-pkg-loader's (née warg-loader) current config format:

default_registry = "example.com"

[namespace.wasi]
registry = "wasi.dev"

[registry."example.com"]
type = "oci"
auth = { username = "open", password = "sesame" }

[registry."wasi.dev"]
type = "oci"
auth = "cGluZzpwb25n"

[lann]

It would be nice to have a wasm-pkg config subcommand to interact with this global config (a la git config): #5

[lukewagner]

That looks great!

[oovm]

Should we consider adding wit.lock at the same time?

If the package can be deleted and re-uploaded, it is unsafe to index by name and version number. Hash256 is the real way to distinguish packages.

In the case where the name is the same but different from the hash stored in the lock, a red warning should be displayed.

Some dangerous situations have occurred and a malicious attack may have occurred.

[calvinrp]

@oovm Thank you for asking. Lock files are definitely a requirement. In the case of the wit CLI, there is a wit.lock already implemented.

[lann]

I wonder if it would make sense to have a single lock file across different tools, e.g. wasm-pkg.lock. Would you ever want different resolved package versions for different tools in the same workspace?

[lann]

#15