Tag managment for the `wit-bindgen` pkg and `wit-bindgen-go`

[asteurer]

If we continue forward with having componentize-go hosting the wit-bindgen-go shared bindings, I'm wondering how best to handle wit-bindgen-go depending on the shared bindings that share a tag with componentize-go, and componentize-go using wit-bindgen-go as a dependency.

Here's how this might look:

1. A change is required for the wit-bindgen/wit_async package.
2. Changes are made to the wit_async package and wit-bindgen-go.
3. As soon as a new release of wit-bindgen-go is cut, we would update and cut a release of componentize-go to ensure that the updated wit-bindgen-go logic matches the packages that are hosted in componentize-go.

@ricochet @dicej Is this the best way for us to handle this, or is there an alternative I may not have considered?

[asteurer]

We would also need to make sure that wit-binden-go is explicit about the componentize-go version to be associated with the generated bindings, e.g. we would specify go.bytecodealliance.org/wit-bindgen v0.3.0 in wit-bindgen-go, and then after it releases, cut the v0.3.0 release of componentize-go.

[dicej]

Can you help me understand how and why this circular depedency between wit-bindgen-go and componentize-go came about? I didn't realize that was the case, and I'm wondering if there's some way we can avoid the cycle and still provide a good developer experience. Otherwise, release management is definitely going to be awkward.

[asteurer]

@dicej I have been working with Bailey to move the go.bytecodealliance.org endpoint to componentize-go assuming that it would make things simpler. I'm wondering if it might be better to move it to the bytecodealliance/go-vanity-urls repo. If you have thoughts, I'm definitely open to any and all suggestions.

[dicej]

@dicej I have been working with Bailey to move the go.bytecodealliance.org endpoint to componentize-go assuming that it would make things simpler. I'm wondering if it might be better to move it to the bytecodealliance/go-vanity-urls repo. If you have thoughts, I'm definitely open to any and all suggestions.

This is the first time I've heard of that repo, but I agree it seems tailor-made for this purpose. In short, we'd update that repo to include endpoints for the wasm-tools, wasmtime, go-modules, and componentize-go projects, correct? If so, that sounds great to me.

[asteurer]

Awesome. I am a little concerned about potential awkwardness that may come from juggling the separate go-vanity-urls repository with wit-bindgen-go requiring the shared bindings for unit tests. Here's one way the release workflow might go:

• Changes are made to to the wit_async package, and a new release is tagged in go-vanity-urls
• The updated files are then copied to wit-bindgen-go and the necessary changes are made to the codegen logic (e.g. package versions, renaming things, unit tests, etc.)

@dicej Am I on the right track, or is there a better way to handle this?

[dicej]

go-vanity-urls will only have redirects like https://github.com/bytecodealliance/go-vanity-urls/blob/main/wasm-tools/index.html and thus will hardly ever change, correct? It won't have any .go files or anything like that, so I don't think there's anything to coordinate. We just add two new redirects in addition to the two that are already there and then forget about it. Am I missing something?

[asteurer]

The issue I'm seeing is that we are hoping to have a vanity URL for the wit-bindgen-go shared bindings, which leaves us with a couple of options (@ricochet feel free to correct me here):

1. We place a go.mod file in the root of wit-bindgen and have folks access the shared bindings via e.g.go.bytecodealliance.org/crates/go/src/package/wit_async
2. We keep a copy of the shared bindings in both wit-bindgen-go (for unit testing) and the go-vanity-imports (for actual downstream use).

The downside of option 1 means that the vanity import is going to be ugly. The downside of option 2 means introducing a little more complexity to the release cadence for wit-bindgen-go. Is there perhaps a 3rd option I haven't yet considered?

[dicej]

I guess I assumed we'd add a file like this to go-vanity-urls which would allow code to refer to e.g. go.bytecodealliance.org/wit-bindgen-go/wit_async, which would redirect to github.org/bytecodealliance/wit-bindgen/crates/go/src/package/wit_async.go automatically:

<html>
  <head>
    <meta
      name="go-import"
      content="go.bytecodealliance.org/wit-bindgen-go git https://github.com/bytecodealliance/wit-bindgen/crates/go/src/package"
    />
  </head>
</html>

But perhaps I'm misunderstanding how this kind of thing works, and I'm not sure how that interacts with package versions and Git tags.