Stream: git-wasmtime

Topic: wasmtime / issue #6543 Why does the file layout for the `...

Wasmtime GitHub notifications bot (Jun 08 2023 at 18:57):

brettcannon opened issue #6543:

Specifically, is there a reason why https://wasmtime.dev/install.sh put wasmtime into a bin directory but the .tar.xz doesn't?

Wasmtime GitHub notifications bot (Jun 12 2023 at 18:13):

alexcrichton commented on issue #6543:

As for "why" I don't think there's any reason other than "two different people worked on these features". It should be fine to update on or the other, probably updating the .tar.xz files produced in CI here is the way to go (probably in this script)

Wasmtime GitHub notifications bot (Jun 12 2023 at 22:05):

brettcannon commented on issue #6543:

Looking at the script I can see not wanting to do it differently simply because what's the answer for Windows versus Unix? :sweat_smile: Is the answer still bin/ for the wasmtime.exe binary?

I ask as I'm happy to submit a PR to change that script as desired (although it probably also requires changing the install.sh script to just do a direct unpacking instead of having to copy wasmtime around).

Wasmtime GitHub notifications bot (Jun 13 2023 at 21:09):

alexcrichton commented on issue #6543:

Ah I don't really know of a standard layout myself so I'm not really sure what the best answer here is. That's a good point though that install.sh will have to account for this one way or another, and that probably needs to land before the change to Wasmtime lands to change the script.

Wasmtime GitHub notifications bot (Jun 14 2023 at 18:30):

brettcannon commented on issue #6543:

I also totally understand if the answer is, "no specific reason it's that way", and that's the end of the conversation. I'm thinking about what the best way to install wasmtime in GitHub Actions and I don't like using install.sh as it assumes shell changes. But then there's this difference with the .tar.xz file where either you copy wasmtime to somewhere or you put the whole directory that you unpack on to PATH.

Wasmtime GitHub notifications bot (Jun 14 2023 at 21:07):

alexcrichton commented on issue #6543:

Heh that's a good question and use case, and one I've often wondered myself! The easiest by far is - run: cargo install wasmtime-cli but that's slow. You can add caching to make it faster but that gets sort of unwieldy and annoying to manage. You could otherwise have a macos/unix/Windows-specific block to download each binary and install them and add them to PATH, but I also find that pretty unwieldy.

Basically I've never found a great way to install precompiled binaries on github actions, but if there's an action like "go download this release for the current platform from this repo" and all we need to do is restructure the tarballs we should definitely do that. I'm not aware of one myself though.

Wasmtime GitHub notifications bot (Jun 15 2023 at 21:59):

brettcannon commented on issue #6543:

You could otherwise have a macos/unix/Windows-specific block to download each binary and install them and add them to PATH, but I also find that pretty unwieldy.

That's what I'm currently doing: https://github.com/brettcannon/cpython-wasi-build/blob/fd3334ec713145686bf8b634354cfe82889ff2f3/.github/workflows/release.yml#L32-L38

I did open #6101 for the idea of putting something like the above behind an action that takes care of those details for you. I think the trick is how to handle what version to download (e.g., can you leave it blank, just say 9, etc.). After that I don't know how much to care about what might end up on PATH (and hence this issue :sweat_smile:)?

Wasmtime GitHub notifications bot (Jun 16 2023 at 20:39):

alexcrichton commented on issue #6543:

Ah indeed! I think that #6101 is probably the "best" solution here in the sense that PATH isn't really all that important and it's "just" a means to an end.

For versioning one option would be to bake it into the tag (e.g. uses: bytecodealliance/wasmtime/install@v9.0.0) although having it as a with: argument also seems reasonable

Wasmtime GitHub notifications bot (Jun 16 2023 at 22:01):

brettcannon commented on issue #6543:

For versioning one option would be to bake it into the tag (e.g. uses: bytecodealliance/wasmtime/install@v9.0.0)

My one concern with that would be what if there was a bug in the action or some changed required (e.g., GitHub is forcing all the Node-based actions to upgrade to Node 18 right now)? I guess as long as you are always willing to move the tags to match the version then it should work, although updating all of those tags when there's been a fix would be a bit of a headache.

having it as a with: argument also seems reasonable

That's probably the best, it just becomes a question of whether it's okay to require the full version (e.g., 9.0.0) or if you could leave bits off and have them filled in (e.g. 9 gets you 9.0.4), and is it worth the effort to make that work? Would most people want the latest or a specific version for some reason? Or would it be better to just have the action for the latest and provide the YAML snippet for those that need a specific version?

Wasmtime GitHub notifications bot (Jun 20 2023 at 15:30):

alexcrichton commented on issue #6543:

True! Tags are probably not the way to go then. I'd probably say though that it's ok to start off simpler by specifying a full version number rather than having to figure out how to expand partial versions as that can always be added later

Last updated: Oct 23 2024 at 20:03 UTC