[feat] add support for cargo's `workspace-inheritance` feature that has already been released in stable

[BLucky-gh]

Describe the problem

The workspace-inheritance feature that lets the programmer specify some stuff at the workspace level and refer to it within a given member crate's Cargo.toml is already stabilized in beta 1.64 and is set to release in September, but from what I have seen it is still not supported in tauri, so I think it should already be implemented.

By not supported in tauri I mean that the build.rs script supplied by cargo tauri init seems to try parsing Cargo.toml but fails with invalid type: map, expected a string for key 'package.version' at line 3 column 21: invalid type: map, expected a string for key 'package.version' at line 3 column 21

Describe the solution you'd like

I'd like for tauri to successfully compile when I refer to workspace-wide settings within Cargo.toml

Alternatives considered

No response

Additional context

Link to the feature: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance

[chippers]

so i think it can already be implemented

I don't really keep track of nightly Rust, is this already in it? If so, I would be willing to co-operate with whatever cargo is planning.

[BLucky-gh]

I don't really keep track of nightly Rust, is this already in it?

It's already stabilized in beta and will be published on stable in September with cargo 1.64, as I've mentioned in the original comment.
While I understand keeping track of nightly is a bit too much, at least keeping track of beta to push updates before a cargo update breaks something is a good idea imho.

[chippers]

while i would really like this for tauri, we are currently trying to support a MSRV of 1.59

[BLucky-gh]

Well, the feature is already in Rust 1.64, so it's already a stable feature, I don't think adding a check like "if for example version is a map instead of a string and contains workspace = true then check workspace" would break compatibility with the Minimum Supported Rust Version, this doesn't change the default behavior, only adds new code that's now considered valid, so backwards compatibility is not broken

EDIT: or did I misunderstand you and did you just mean that you're prioritizing getting the MSRV to 1.59 over implementing newer features?

[chippers]

i havent tested this yet, but i want to prioritize these workspaces working completely with 1.59

using the tauri workspace as a path/git repo will break of course (i dont think thats a problem), but i would want to verify that the MSRV doesn't bump up when using tauri as a crate

[chaynabors]

👋 @withfig engineer here. We're using workspace inheritance for all of our internal crates now. We've got a workaround in place for our tao+wry app but this functionality would be really nice to have. In our case, the important thing is that cargo-tauri build correctly parses the workspace inherited keys if they exist.

[TheButlah]

As best as i can tell, this is causing my cargo tauri build to fail. I'll have to remove the workspace inheritance