Duplicate definitions with name <..>

[odyslam]

I have gotten this error with both 8.1.x and 8.2.x and tried multiple times to delete the registry and re-download/re-compile.

error[E0592]: duplicate definitions with name `inner_add_git_map_entries`
   --> /Users/odysseas/.cargo/registry/src/index.crates.io-6f17d22bba15001f/vergen-8.2.4/src/feature/git/cmd.rs:520:5
    |
520 | /     fn inner_add_git_map_entries(
521 | |         &self,
522 | |         path: Option<PathBuf>,
523 | |         idempotent: bool,
...   |
526 | |         rerun_if_changed: &mut Vec<String>,
527 | |     ) -> Result<()> {
    | |___________________^ duplicate definitions for `inner_add_git_map_entries`
    |

[CraZySacX]

Looks like you don't have the git feature configured correctly. Check out the docs. If that doesn't help, send me the snippet of your Config.toml where you are defining the vergen dependency.

[odyslam]

@CraZySacX it seems that it's configured correctly. git eixsts in PATH.

Here is my config.toml snippet:

[build-dependencies]
vergen = { version = "8.1.0", default-features = false, features = [
  "build",
  "cargo",
  "git",
  "gitcl",
] }

[nikitaNotFound]

Hi, any updates?

[odyslam]

Still encountering this

[CraZySacX]

I'm going to need much more information (the output from rustc -Vv and cargo -Vv would be a good start). I cannot reproduce this issue on my mac, linux, or windows environments. Every feature combination is run out in CI as well on all three environments, on stable, beta, nightly, and 1.68.0 (MSRV).

[odyslam]

Could it be because I am using a git dependency that also uses vergen ? Some times cargo glitches with git imports. Let me look into it.

[CraZySacX]

That is likely the cause. vergen is intended for use with binaries, so I've never seen it included as part of a library. I'll setup that scenario locally to see if I can reproduce this (and see if it's solvable).

[zerosnacks]

Running into the same issue and I suspect the same cause (attempting to use a git dependency that uses vergen itself).

[CraZySacX]

Running into the same issue and I suspect the same cause (attempting to use a git dependency that uses vergen itself).

I wasn't able to reproduce this error with a simple setup I made locally. However, I was able to reproduce it on the mev project you referenced.

I was able to get the mev binary to build with vergen in a strange manner. I set the build-dependencies as below

[build-dependencies]
vergen = "8.2.10"

and the build.rs as

use std::error::Error;
use vergen::EmitBuilder;

fn main() -> Result<(), Box<dyn Error>> {
    // Emit the instructions
    EmitBuilder::builder()
        .git_sha(true)
        .build_timestamp()
        .cargo_features()
        .cargo_target_triple()
        .emit()?;
    Ok(())
}

This shouldn't work as there are no features declared on the top-level vergen build dependency, but it's compiles and runs happily. My hunch is cargo is doing something funky when determining features for a build dependency that is declared across multiple Cargo.toml. I'll take a look at the cargo source later this week to see how that is happening.

[CraZySacX]

Could it be because I am using a git dependency that also uses vergen ? Some times cargo glitches with git imports. Let me look into it.

@odyslam could you try the workaround I described above (declaring the vergen dependency with either no features turned on, or only the features that differ from the upstream dependency feature set).

[CraZySacX]

I found the cause. cargo performs a union of all the features declared for a dependency (https://doc.rust-lang.org/cargo/reference/features.html#feature-unification). The gitcl, git2, and gitoxide features are mutually exclusive right now which is not recommended (https://doc.rust-lang.org/cargo/reference/features.html#mutually-exclusive-features). In order to fix this properly, I would have to completely re-architect the git feature. For now, take a look at these inspections and hopefully the your feature set overlap.

In the meantime, I'll try to figure out how to re-architect to avoid this problem. Going to close this as there is a 'workaround'. Will be starting work on version 9 to resolve correctly.