Design reasoning behind global config

[Exidex]

I have asked this in the bytecode alliance zulip, but haven't gotten any answers. Maybe here is a better place

I am having troubles understanding the design of the wkg. Specifically why is it not possible to define registries in the wkg.toml. lets say for my plugin system, I have an arbitrary wasm oci artifact published at ghcr.io, how can I use it as a dependency in the wit? I am very likely missing something, but it seems that currently it requires you to specify custom registry in global config, which makes project not portable? you can use wkg --config option which points to file in the project, but then you have to use this option every time you use wkg which makes it feel like a workaround

[calvinrp]

Yeah, I agree and makes sense to have the wkg.toml in a project support registry mappings. Happy to accept a PR.

[Exidex]

What was the reasoning for global config instead of per project one? To me that seems like very unusual approach so much that i struggle to came up with use case for it

[lann]

Global config is most useful today for wasi.dev which provides official packages for the wasi:* proposals. That default mapping is baked in to the binary but the global config file lets you override it if you'd rather use e.g. a local mirror.

Another use case would be an organization-private registry where org members could configure e.g. myorg:* to registry.myorg.com.

[mkatychev]

@Exidex we're planning on moving to config-rs for 0.17 release

feat(config,client): provide a per-registry envvar scheme to set autentication by mkatychev · Pull Request #237 · bytecodealliance/wasm-pkg-tools and we've also recently exposed setting authentication on a per-registry basis through envvars:

WKG_REGISTRY_<REGISTRY>_AUTH_<AUTH_SCHEME>