Cargo should support configuration in non-hidden files.

[jrvanwhy]

Describe the problem you are trying to solve

Currently, cargo searches for configuration files by looking for a directory named .cargo, which is a hidden directory. This means that a typical ls invocation does not reveal the existence of a config file. This makes it difficult to debug problems caused by cargo config files, particularly for contributors who are new to a project.

Describe the solution you'd like

I would like Cargo to search for a config file in a non-hidden location, such as cargo/config. This way projects that want to use Cargo configs and make that config visible can do so.

Alternative idea in case searching in a new location is considered a breaking change: We could add a field to Cargo.toml pointing to the Cargo config to use when invoked from within a particular crate or workspace.

Notes

The Tock project uses Makefiles to pass flags to rustc and the linker rather than using a cargo config because they do not want to have any configs in hidden files.

[jrvanwhy]

Adding @ppannuto from the Tock project.

[ppannuto]

It's not just ls, the majority of tools (find, grep, etc) will ignore hidden files.

Putting critical build configuration in files that standard tools will not find makes discovery very challenging for new and even experienced users. Particularly in embedded systems contexts, non-trivial compiler customization is often necessary, and it's important that how targets are configured be easily visible.

From our experiences with TinyOS, using any hidden files to drive configuration is a non-starter for Tock.

[malaire]

I agree. The Cargo.toml is not hidden and so requiring .cargo/config to be hidden is not consistent.

[epage]

Generally, when I see projects do this, they use a _ prefix instead to sort these "semi-hidden" files and directories separately from the rest.

: We could add a field to Cargo.toml pointing to the Cargo config to use when invoked from within a particular crate or workspace.

Config files are environment configuation, distinct from project configuration, see #12738

[joshtriplett]

We talked about this in today's @rust-lang/cargo meeting. We're sympathetic to the desire to have Cargo configuration visible. However, this would be a massive amount of churn in the community (affecting more tools than just Cargo), as well as inconsistency with ~/.cargo/config.toml in the user's home directory (which shouldn't be a visible directory, because it's in the user's home directory). There are also many other tools apart from Cargo that use dot directories.

As a result, we don't want to do a migration for this.

In general, we would like to migrate many items that currently require .cargo/config.toml to support using Cargo.toml instead.

As a workaround, we would suggest creating a symlink instead (e.g. from .cargo/config.toml to Cargo-config.toml). Or, once the config-include feature becomes stable, you could use that.