[bug] Improve error messages if cargo metadata fails.

[jmetz]

Describe the bug

Running:

cargo create-tauri-app or sh <(curl https://create.tauri.app/sh)

• Tried rust-based (tried vanilla and leptos) frontend as well as Typescript based (vanilla with pnpm or deno)

then

cargo tauri android init or pnpm tauri android init or deno task tauri android init all produce:

failed to get cargo metadata: expected value at line 1 column 1

Trying cargo tauri dev instead of android init gives the same issue.

Adding verbose flag with -v doesn't give any useful info.

Apologies in advance if this is something trivial I've missed; at the same time, the quickstart should be as foolproof as possible IMO, so this could still highlight an area for improvement.

Reproduction

sh <(curl https://create.tauri.app/sh)
# Select any frontend option
cargo tauri android init 
# OR
cargo tauri dev

Expected behavior

Should android init should create android scaffold, or cargo tauri dev should correctly build app and launch dev server.

Full tauri info output

cargo tauri info


[✔] Environment
    - OS: EndeavourOS Rolling Release x86_64 (X64) (Unknown DE on wayland)
    ✔ webkit2gtk-4.1: 2.46.5
    ✔ rsvg2: 2.59.2
    ✔ rustc: 1.83.0 (90b35a623 2024-11-26)
    ✔ cargo: 
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.18.1
    - pnpm: 9.15.3
    - yarn: 1.22.22
    - npm: 11.0.0
    - bun: 1.0.7
    - deno: deno 2.0.6

[-] Packages
    - tauri 🦀: 2
    - tauri-build 🦀: No version detected
    - wry 🦀: No version detected
    - tao 🦀: No version detected
    -  🦀: cargo 1.83.0 (5ffbef321 2024-10-29)
    - @tauri-apps/api : 2.2.0
    - @tauri-apps/cli : 2.2.2

[-] Plugins

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - bundler: Vite

Stack trace

failed to get cargo metadata: expected value at line 1 column 1

Additional context

No response

[FabianLars]

thanks for the report. Since it's missing in the tauri info output for some reason, could you share the output of cargo --version please? Also, how did you install cargo?

[jmetz]

Sorry about that - I think the info is above, though only after my edit. cargo was installed with rustup, and the version is

cargo 1.83.0 (5ffbef321 2024-10-29)

(the reason for the odd output above is that I had cargo shadowed by a script that sets RUSTC_WRAPPER=sccache before calling cargo properly, which caused the malformed output of cargo tauri info)

[FabianLars]

thanks. I just tried it on my system and don't see any issues. Can you share the generated Cargo.toml file?

[jmetz]

@FabianLars - Opps! I just renamed my wrapper script and it works fine.

I didn't realise that cargo tauri uses the output of cargo-commands to work; so by adding my wrapper script and slightly modifying that output, it breaks things!

Is it possible to move away from cargo tauri using the CLI output of the cargo command? That said, I can see that that might be tricky or undesirable.

Perhaps this should instead be a request to improve the error message; something about not being able to correctly parse the output of cargo would be more useful than failed to get cargo metadata. That message had me thinking the issue must be in Cargo.toml or something.

[FabianLars]

in development you can use cargo run just fine. you just have to run the beforeDevCommand yourself in another terminal.

For building apps you can also use cargo build --release plus the beforeBuildCommand but if you also want to bundle them into installers then you need cargo tauri.

Is it possible to move away from cargo tauri using the CLI output of the cargo command? That said, I can see that that might be tricky or undesirable.

This would require us to copy a shit ton of logic out of cargo itself and keeping that up to date, so i'd really rather not tbh, especially since this is the first time it ever caused problems iirc.

But yeah, the error message should be improved (like almost all current error messages...)

[jmetz]

Understood - in that case, I'll rebrand this as a request to improve that error message. Thanks for the fast response and helping me figure out the issue!

…

On Mon, 6 Jan 2025, 13:58 Fabian-Lars, ***@***.***> wrote: in development you can use cargo run just fine. you just have to run the beforeDevCommand yourself in another terminal. For building apps you can also use cargo build --release plus the beforeBuildCommand but if you also want to bundle them into installers then you need cargo tauri. Is it possible to move away from cargo tauri using the CLI output of the cargo command? That said, I can see that that might be tricky or undesirable. This would require us to copy a shit ton of logic out of cargo itself and keeping that up to date, so i'd really rather not tbh, especially since this is the first time it ever caused problems iirc. But yeah, the error message should be improved (like almost all current error messages...) — Reply to this email directly, view it on GitHub <#12273 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAO4IJH6BJPEYCJFWG2KZX32JJ4YHAVCNFSM6AAAAABUVQFYP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNZTGA3DAOJZGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>