rustyhorde / vergen

Generate cargo instructions at compile time in build scripts for use with the env! or option_env! macros
Apache License 2.0
370 stars 55 forks source link

Environment values should not be `VERGEN_IDEMPOTENT_OUTPUT` on failure #299

Open holly-hacker opened 7 months ago

holly-hacker commented 7 months ago

I am using the following configuration:

pub fn main() {
    vergen::EmitBuilder::builder()
        .idempotent()
        .quiet()
        .all_cargo()
        .all_git()
        .git_describe(true, false, None)
        .all_rustc()
        .emit()
        .unwrap();
}

Due to an error on my end, there was no .git folder in my build environment which means the git env vars could not be populated correctly. However, the value of each git environment value was VERGEN_IDEMPOTENT_OUTPUT which is very unexpected and cost me a lot of time troubleshooting in the wrong direction. Ideally, these should be filled with another value to indicate the error.

I understand that the .quiet() call and lack of .fail_on_error() make this error harder to spot, but I still think the current behavior is very weird.

CraZySacX commented 7 months ago

This behavior is intentional. As a build tool, I don't want vergen to block your build if something has failed internally, unless specifically configured. So by default vergen will populate with those values unless you turn on fail_on_error. With quiet off, you would get warnings that those values had been replaced. I recommend developing with fail_on_error turned on and quiet off. When you reach a stable state, flip them off.

holly-hacker commented 7 months ago

I understand that it is intentional to fill in some value rather than fail by default, but this issue is to report that it should be a different value that indicates that the value is filled in because of an error, not because the value is not idempotent. It doesn't make sense for VERGEN_GIT_SHA to ever be VERGEN_IDEMPOTENT_OUTPUT because the value should always be stable.

teythoon commented 4 months ago

I also find the behavior not helpful. We use VERGEN_GIT_SHA to compute a version string. If we build from a tarball, with .git being absent, we get a string like 1.8.1-VERGEN_IDEMPOTENT_OUTPUT+sequoia-openpgp-1.19.0.

In previous versions of vergen, the environment variable was simply absent. I think I'll try to go back to this behavior by opting in to the errors, and ignoring them.

kingwingfly commented 3 months ago

I think that leaving env variable unset and only showing a warning may be better. In my case, if there's no git tree, all I could do is to panic during building or got a meaningless VERGEN_IDEMPOTENT_OUTPUT.

Currently, my solution is separating EmitBuilder apart:

EmitBuilder::builder()
        .fail_on_error()
        .git_describe(false, true, None)
        .git_commit_timestamp()
        .emit()
        .ok();
    EmitBuilder::builder()
        .rustc_host_triple()
        .rustc_channel()
        .rustc_semver()
        .emit()
        .unwrap();

And got version str by option_env!:

const VERSION: &str = const_format::formatcp!(
    "{} {}\nRUSCT {} {} {}",
    match option_env!("VERGEN_GIT_DESCRIBE") {
        Some(var) => var,
        _ => concat!(env!("CARGO_PKG_VERSION"), "+"),
    },
    match option_env!("VERGEN_GIT_COMMIT_TIMESTAMP") {
        Some(var) => var,
        _ => "unknown-timestamp",
    },
    env!("VERGEN_RUSTC_HOST_TRIPLE"),
    env!("VERGEN_RUSTC_CHANNEL"),
    env!("VERGEN_RUSTC_SEMVER")
);
CraZySacX commented 1 month ago

Here is some additional background on this "feature". There was an issue with packages built from tarballs where the user didn't have control over the source code (in this particular case a Linux package maintainer) and the git variables were causing failures because they weren't building from a repository. In parallel, there was a request to be able to force idempotent (or as close as possible with Rust) builds that didn't include non-idempotent items such as timestamps every time the code was built. This solution covered both bases.

I can see how this fix of two issues with one type of output is causing some confusion in the regular use case of the tool. I'll probably tweak the "don't fail unless I've requested it" output to be different from the force idempotent output.