brettcannon opened issue #6543:
Specifically, is there a reason why https://wasmtime.dev/install.sh put
wasmtime
into abin
directory but the.tar.xz
doesn't?
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)
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 thewasmtime.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).
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.
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 copywasmtime
to somewhere or you put the whole directory that you unpack on toPATH
.
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.
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 onPATH
(and hence this issue :sweat_smile:)?
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 awith:
argument also seems reasonable
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 reasonableThat'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 you9.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?
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: Dec 23 2024 at 12:05 UTC