User global default registry config

[lann]

One important bit of global config (ref #3) is a user's global default (aka "home") registry.

There is support for this in other ecosystem tools like cargo, npm, and pip, though the global default typically has a ecosystem-standard value (crates.io, npm.io, pypi.org) and (in my experience) is rarely changed outside of certain corporate environments, while we have been aiming for a more decentralized ecosystem of federated registries.

My UX suggestions:

• The implicit default registry (i.e. when no config file specifies a default) for BA-maintained tools should be bytecodealliance.org
• It should be relatively straightforward for users to set a default registry by expressing an explicit intent to do so, e.g. wasm-pkg config --default-registry=example.com
• For certain interactive flows where a user is explicitly choosing to associate with a particular registry - like warg login - it could interactively suggest setting the default, something like:

  $ warg login example.com
  ...
  Your current default registry is "bytecodealliance.org"; would you like to update the default to "example.com"? [y/N]
  

  • This has the potential to be a bit of a nuisance if someone needs to log in to non-home registries regularly. Maybe this interaction should only trigger if there is no explicit global default set?
  • Note: This is a UX change from the current warg login --registry ... behavior which unconditionally sets the global default. This current behavior seems too surprising as the command arguments do not imply any sort of global config update apart from credentials.

[calvinrp]

To confirm, we should make the following change:

1. the default registry for all non-configured warg and wasm-pkg-tools would be bytecodealliance.org

2. warg login --registry ... and warg config --registry ... should explicitly ask the user to confirm that they want to change their default / home registry to that registry URL

3. other tools that use warg client (cargo-component, wac, wit, wasm-pkg-tools, etc) should ask the user to confirm (and remember?) that they want to use warg global config

4. print out the registry being used after each command usage

@lann and @lukewagner is that in line with your thinking?

[lukewagner]

That mostly sounds right, but could you explain a bit more about how, in (3), these tools use the warg client and warg global config -- is that distinct from wasm-pkg-tools and the wasm-pkg-tools global config or used transitively via these tools?

[calvinrp]

Currently, if you have the warg CLI configured, the tools that integrate the warg-client will use the global config unless you override with tool-specific configuration or CLI flags. It has the nice property of things just working out of the box and likely does what you expect and want. That includes the key management and authentication through your home registry.

However, things quickly start getting wonky when you override those values in a specific tool without full understanding. If you don't care about publishing or authentication or federation, it might be OK. But if you do, then the behavior may be unexpected. Unfortunately, with secrets and federation mappings things get complicated. It isn't simply overriding a single registry value.

If you have warg configured with something like wa.dev, you can do the following without per-tool level config...

cargo component new --target fermyon:spin/http-trigger --lib my-pkg (pending release of merged code)
and
cargo component publish for your newly authored component

or

wac plug macovedj:hashimap-service --plug macovedj:my-component -o plugged.wasm (Pending PR)

cargo-component, wac, wit, wasm-pkg-tools and wow all have Warg integration today.

[lann]

Does the approach in #3 (reply in thread) help resolve this?

[calvinrp]

Yeah, I think so and a reasonable plan.