search

framesurge / perseus

A state-driven web development framework for Rust with full support for server-side rendering and static generation.
https://framesurge.sh/perseus/en-US
MIT License
2.15k stars 89 forks source link

Tool extraction failure #229

Closed quinn closed 1 year ago

quinn commented 1 year ago

This issue is reporting a bug in the code of Perseus. Details of the scope will be available in issue labels. The author described their issue as follows:

error with perseus serve immediately after running perseus new

The steps to reproduce this issue are as follows:

$ perseus new appname
Your new app has been created! Run perseus serve -w to get to work! You can find more details, including about improving compilation speeds in the Perseus docs (https://arctic-hen7.github.io/perseus/en-US/docs/). $ cd appname/src $ perseus serve -w
🔏 Generating Cargo lockfile...✅ 📥 Installing external tools...❌ Error: couldn't extract 'wasm-opt' (do you have the necessary permissions?)

Caused by: failed to iterate over archive Caused by: failed to fill whole buffer

A minimum reproducible example is available at <>.

Tribble internal data dHJpYmJsZS1yZXBvcnRlZCxDLWJ1ZyxBLWNsaSxhdXRob3Itd2lsbGluZy10by1pbXBs
arctic-hen7 commented 1 year ago

Hmm, that's extremely weird. What's your OS?

quinn commented 1 year ago

@arctic-hen7 Ubuntu 22.04, also worth mentioning (thought I posted with issue) i'm on perseus 0.4 beta

This wasn't happening before, just started happening, which is what led me to try generating a new app

It sounds like a file perm error, where is wasm-opt being axtracted to?

arctic-hen7 commented 1 year ago

Hmm, same. It's extracted to your system cache directory, which should be something like ~/.cache/perseus-cli/tools for you. Could you try clearing that directory? Perseus should use the local dist/ directory if it finds the systemwide cache unusable, which implies that this might have been caused by a corruption of some sort. I've experienced some weird Cargo failures causing tool reinstallation in the past, so it could be something like that.

arctic-hen7 commented 1 year ago

UPDATE: This is now occurring on CI, so I think this might be a critical bug that's worked its way into the installation process somehow.

arctic-hen7 commented 1 year ago

Okay, this has been caused by the wasm-opt team releasing a new version without including any release artifacts. The CLI defaults to the latest version, and it can't find the artifacts, hence the problem! Add --wasm-opt-version version_110 to the first Perseus command you run, and everything will work perfectly. (You won't need to add this flag again.)

arctic-hen7 commented 1 year ago

See WebAssembly/binaryen#5282.

quinn commented 1 year ago

thank you! that fixed it. Fixed by running:

perseus serve -w --wasm-opt-version version_110

subsequent runs work without the flag:

perseus serve -w
arctic-hen7 commented 1 year ago

The artifacts for wasm-opt's parent package have now been released for v111, so this problem should no longer affect anyone! I'll leave this issue open until the upstream one is definitely closed, and then I'll remove the warning in the README.