kornelski / cargo-deb

Make Debian packages directly from Rust/Cargo projects
https://lib.rs/cargo-deb
MIT License
431 stars 52 forks source link

Option to read version from CARGO_PKG_VERSION #142

Open rovo-dave opened 1 month ago

rovo-dave commented 1 month ago

The version of my package is currently determined dynamically within the build.rs build script and passed the package targets via CARGO_PKG_VERSION. The version field is removed from cargo.toml so it never has to be manually updated there.

Is there anyway that cargo-deb could use the value of CARGO_PKG_VERSION (read after the package is built, or at least after build.rs) rather than the current options which are either the value of version in cargo.toml or the version passed into cargo-deb on the command line?

kornelski commented 1 month ago

How does that work? CARGO_PKG_VERSION should be set by Cargo, not by you for Cargo.

Does cargo metadata see the expected version of your package?

rovo-dave commented 1 month ago

My build.rs file contains this:

println!("cargo:rustc-env=CARGO_PKG_VERSION={}", dynamic_version);

and clap builder has this:

#[command(version = env!("CARGO_PKG_VERSION"))]

version is left out of cargo.toml. cargo metadata shows the version as 0.0.0. This is not a crate that gets published to a registry so I only really care about what the deb package is versioned as and what the --version arguments outputs from my binary.

I have seen other projects modify CARGO_PKG_VERSION this way. If it is bad form I can always make up my own environment variable. Regardless, I was looking for a way to seed cargo-deb with a version that is only available after build.rs is executed.

kornelski commented 1 month ago

env vars you set for rustc from build.rs are invisible to the world outside (env vars are not global variables, they have scoping per process, setting them only downwards), so I don't think there's a reasonable way to get that info.

Overwriting Cargo's variable does look like a hack. I wouldn't be surprised if this wasn't supposed to be allowed, but Cargo just never though to block that explicitly, but could start treating these names as reserved in the future.

It would be possible for cargo-deb to set an env var for the build like DEB_PACKAGE_VERSION, and have your code read that instead.