Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] tauri build modifies Cargo.toml? #8711

Open
ReactorScram opened this issue Jan 30, 2024 · 9 comments
Open

[bug] tauri build modifies Cargo.toml? #8711

ReactorScram opened this issue Jan 30, 2024 · 9 comments
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug

Comments

@ReactorScram
Copy link

Describe the bug

Running stat src-tauri/Cargo.toml && pnpm tauri build --bundles none > /dev/null 2> /dev/null && stat src-tauri/Cargo.toml

I see the mtime for my Cargo.toml changes after pnpm tauri build. If I do the same with only cargo build --release, the mtime doesn't change, so I think it must be in Tauri.

image

My beforeDevCommand and beforeBuildCommand are empty strings, so I don't think anything else in my build pipeline should be modifying the Cargo.toml manifest.

Reproduction

I can go back and make a repro repository, I'm just curious if this is intended behavior and if there's anything I can do to disable it.

Expected behavior

I expect Cargo.toml to not change during the build process.
I'm trying to embed the Git version in my final exe and for some possibly Windows-specific reason, this modification is causing the Git version to show up as dirty / modified

Full tauri info output

[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 120.0.2210.144
    ✔ MSVC:
        - Visual Studio Build Tools 2019
        - Visual Studio Community 2022
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: 1.75.0-x86_64-pc-windows-msvc (overridden by 'C:\cygwin64\home\User\projects\firezone\rust\rust-toolchain.toml')
    - node: 20.10.0
    - pnpm: 8.14.3
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 1.5.4
    - tauri-build [RUST]: 1.5.1
    - wry [RUST]: 0.24.7
    - tao [RUST]: 0.16.5
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../src
    - devPath: ../src

Stack trace

N/A

Additional context

I searched in issues and docs but of course "Cargo.toml" and even "manifest" returned a lot of false positives, so maybe I missed something.

@ReactorScram
Copy link
Author

I think it might be for this feature injection thing:

let persist = inject_features(&mut manifest, &mut dependencies)?;
let tauri_features = dependencies
.into_iter()
.find(|d| d.name == "tauri")
.unwrap()
.features;
if persist {
let mut manifest_file =
File::create(&manifest_path).with_context(|| "failed to open Cargo.toml for rewrite")?;
manifest_file.write_all(

@FabianLars
Copy link
Member

yep, that's it. You can disable it by using workspace inheritance for the tauri dependency as a workaround.
We should add a check for this though, i think we have that for the plist files too already.

@ReactorScram
Copy link
Author

For the Tauri dep itself, e.g. tauri = { workspace = true }?

For anyone else who runs into this, it ultimately turned out to be a problem with line endings, which I solved (assuming the PR is merged) by adding a .gitattributes file with * -text: https://github.com/firezone/firezone/pull/3432/files

I still don't love rewriting Cargo.toml, but the rewrite was actually correct, it's just that Github had it out on our Windows runner as CRLF and then the toml_edit crate must have rewritten it as LF.

I wish CRLF would just disappear, I'm pretty sure modern Windows tools all handle LF just fine :/

@FabianLars
Copy link
Member

For the Tauri dep itself, e.g. tauri = { workspace = true }?

yup

Okay, the check would probably fail on line endings (or maybe we have that check already and this is exactly what's happening 🤔)

I wish CRLF would just disappear, I'm pretty sure modern Windows tools all handle LF just fine :/

Same :(

ReactorScram added a commit to ReactorScram/toml_edit_repro that referenced this issue Jan 31, 2024
@ReactorScram
Copy link
Author

ReactorScram commented Jan 31, 2024

Nah I didn't have workspace set up, so your check might be okay.

It's just that toml_edit doesn't guarantee byte-for-byte roundtripping. Sometimes it re-orders keys too it seems, known issue - toml-rs/toml#163 (Although if that was the only problem, and if it was deterministic, I'd just check in the correct order on my dev system)

Anyway here's a repro case where it doesn't round-trip carriage returns https://github.com/ReactorScram/toml_edit_repro/blob/b348a5bbc9ae64b43e4ae82ffbab1fda35f68ca2/src/main.rs#L3

@CrendKing
Copy link

The rewriting Cargo.toml with LF on Windows is annoying. Is there a way to disable the rewriting feature?

@FabianLars
Copy link
Member

#8711 (comment)

@CrendKing
Copy link

CrendKing commented Mar 14, 2024

In my Cargo.toml, I have the following:

[build-dependencies]
tauri-build = { version = '2.0.0-beta', default-features = false, features = ['codegen', 'config-toml'] }

[workspace.dependencies]
tauri = { version = '2.0.0-beta', default-features = false, features = ['protocol-asset'] }

[dependencies]
tauri = { workspace = true }

When build, it is still changing the file to LF. Did I miss something?

@FabianLars
Copy link
Member

maybe try the same with tauri-build 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs triage This issue needs to triage, applied to new issues type: bug
Projects
None yet
Development

No branches or pull requests

3 participants