Support for workspace inheritance

[domenicquirl]

Hi,

the latest Rust release (1.64) includes support for sharing workspace package and dependencies information across workspace members (see the announcement). Using this feature causes cargo deb to fail with the error

cargo-deb: Unable to parse Cargo.toml
  because: invalid type: map, expected a string for key `package.version` at line 5 column 24
  because: invalid type: map, expected a string for key `package.version` at line 5 column 24

(using [workspace.package] version = "<VERSION>").

Looking at your Cargo.toml, I assume this is using cargo_toml to parse the manifest? If that is the case, this might be related to https://gitlab.com/crates.rs/cargo_toml/-/issues/19.

[benferse]

Pretty sure this is in progress. I think @kornelski made the changes required in cargo_toml 0.12.x

[kornelski]

I've added only for dependencies. For other field it's going to be rough, because it makes struct access pretty ugly. I'm not sure how to implement it.

[domenicquirl]

@kornelski do you mean here or in cargo_toml? I haven't looked into it too much, but I expected cargo_toml to mostly implement the Cargo.toml data model.

For other tooling, a lot of which currently faces similar issues, an alternative solution that was suggested is building on cargo metadata instead. I've mostly heard about that in the context of things like cargo outdated or cargo udeps, which currently use cargo as a library (and have not integrated a new version which supports workspace inheritance yet), but maybe it applies here as well. Potential benefits could be

• the result of running cargo metadata is more synced up with the locally installed toolchain. In particular, updating cargo through the toolchain makes new features available independently of the currently installed version of third-party tools and the library versions they are currently using in their dependencies (the local version may also lag behind, in which case the user is unable to use new features regardless).
• the data returned by cargo metadata is already somewhat aggregated, e.g. inherited data is inlined into the respective packages. The metadata format is therefore more stable than individual file formats.

[kornelski]

cargo metadata, ironically, doesn't include package's metadata field required for cargo-deb.

[kornelski]

Done

[domenicquirl]

Hey @kornelski, thanks a lot for picking this up so quickly! 🎉

Do you think you could release a patch that includes #53? I've just been bitten by edition after coming back to this. We've excluded it from inheritance for now so we're able to inherit dependencies and the other metadata. That is working well now with 1.40.3, but since it seems that the issues with edition and readme are already fixed it would be even better if we could have a version with the patch applied that "just works".

Thanks again for your work in maintaining cargo deb - it's great! ☺️

[kornelski]

Published