Module cargo_hakari::config

Configuration for cargo hakari.

Configuration file location

The default config path for cargo-hakari versions 0.9.8 or above is .config/hakari.toml, relative to the root of the workspace. Previous versions used .guppy/hakari.toml, which continues to be supported as a fallback.

Common options

hakari-package

The name of the hakari-managed crate in the workspace. Must be specified. For example:

hakari-package = "my-workspace-hack"

resolver

The version of the Cargo feature resolver to use. Version 2 is highly recommended. For more, see this Rust blog post.

Defaults to “1”, but .config/hakari.toml files created by cargo hakari init set it to “2”.

resolver = "2"

dep-format-version

The version of workspace-hack = ... lines in other Cargo.toml files to use.

Possible values:

• “1”: workspace-hack = { path = ...}. (Note the lack of a trailing space.)
• “2”: workspace-hack = { version = "0.1", path = ... }. This is required for the advanced setup documented in the Publishing section.

Defaults to “1”, but starting cargo hakari 0.9.8, .config/hakari.toml files created by cargo hakari init set it to “2”.

dep-format-version = "2"

platforms

Platforms to run specific queries on.

By default, cargo hakari produces the minimal set of features that can be unified across all possible platforms. However, in practice, most developers on a codebase use one of a few platforms. cargo hakari can run specific queries for a few platforms, producing better results for them.

Defaults to an empty list.

# Unify features on x86_64 Linux, Mac and Windows.
platforms = [
     "x86_64-unknown-linux-gnu",
     "x86_64-apple-darwin",
     "x86_64-pc-windows-msvc",
]

traversal-excludes

Crates to exclude while traversing the dependency graph.

Packages specified in traversal-excludes will be omitted while searching for dependencies. These packages will not be included in the final output. Any transitive dependencies of these packages will not be included in the final result, unless those dependencies are reachable from other crates.

Workspace crates excluded from traversals will not depend on the workspace-hack crate, and cargo hakari manage-deps will remove dependency edges rather than adding them.

This is generally useful for crates that have mutually exclusive features, and that turn on mutually exclusive features in their transitive dependencies.

Defaults to an empty set.

[traversal-excludes]
workspace-members = ["my-crate", "my-other-crate"]
third-party = [
    # Third-party crates accept semver ranges.
    { name = "mutually-exclusive-crate", version = "1.0" },

    # The version specifier can be skipped to include all versions of a crate.
    # (Cryptography-related crates often use features to switch on different backends.)
    { name = "my-cryptography" },

    # Git and path dependencies can also be specified
    { name = "git-dependency", git = "https://github.com/my-org/git-dependency" },
    { name = "path-dependency", path = "../my/path/dependency" }
]

final-excludes

Crates to remove at the end of computation.

Packages specified in final-excludes will be removed from the output at the very end. This means that any transitive dependencies of theirs will still be included.

Workspace crates excluded from the final output will not depend on the workspace-hack crate, and cargo hakari manage-deps will remove dependency edges rather than adding them.

This is generally useful for crates that have mutually exclusive features.

This accepts configuration in the same format as traversal-excludes above.

Defaults to an empty set.

[final-excludes]
workspace-members = ["my-crate", "your-crate"]
third-party = [
    # The "fail" crate uses the "failpoints" feature to enable random errors at runtime.
    # It is a good candidate for exclusion from the final output.
    { name = "fail" },

    # Version specifiers and git/path dependencies work similarly to traversal-excludes
    # above.
]

registries

Alternate registries, in the same format as .cargo/config.toml.

This is a temporary workaround until Cargo issue #9052 is resolved.

Defaults to an empty set.

[registries]
my-registry = { index = "https://my-intranet:8080/git/index" }

Output options

exact-versions

By default, the workspace-hack crate’s Cargo.toml file will contain a semver range. With exact-versions turned on, the exact version currently in use will be output.

This is most useful for situations where the Cargo.lock file is checked in, and if version numbers are kept in sync across Cargo.toml and Cargo.lock. This includes some configurations of Dependabot.

Defaults to false.

exact-versions = true

Advanced options

unify-target-host

Controls unification across target and host platforms.

If the same dependency is built on both the target and host platforms, this option controls whether and how they should be unified.

The possible options are "none", "auto", "unify-if-both", and "replicate-target-on-host". For more about these options, see the documentation for UnifyTargetHost.

Defaults to "auto".

unify-target-host = "replicate-target-on-host"

output-single-feature

By default, cargo hakari only outputs lines corresponding to third-party dependencies which are built with at least two different sets of features. Setting this option to true will cause cargo hakari to output lines corresponding to dependencies built with just one set of features.

This is generally not needed but may be useful in some situations.

Defaults to false.

output-single-feature = true