--manifest-path path/to/NonCargo.toml fails

[gnzlbg]

cargo build --manifest-path=NotCargo.toml 

fails with

the manifest-path must be a path to a Cargo.toml file

but my NotCargo.toml is a manifest file.

So either the option needs to be called --cargo-toml-path, or it should IMO accept any TOML file that's a valid manifest path.

Motivation: working around cargo bugs often requires having many manifests files and using different ones depending on what one is trying to do (e.g. build for two different editions, build without dev-dependencies in the dependency graph, etc.).

[mssun]

Yes, I met the same issue. Can we just delete this check and update related testcases?

cargo/src/cargo/util/command_prelude.rs

Lines 260 to 262 in 9be4594

	if !path.ends_with("Cargo.toml") {
	failure::bail!("the manifest-path must be a path to a Cargo.toml file")
	}

[AmitPr]

This seems like a valuable feature to have, in the case where one codebase has to run through several unique compilation chains, to support things like having a separate Cargo.toml for each target. Looking at this and #10083

[epage]

Going to write up some quick thoughts from different angles.

This would only be able to work with --manifest-path; we wouldn't be able to auto-discover these files (likely people realize this but wanted to be explicit).

Since this was opened, we took advantage of this flexibility in adding support for single-file packages in #12289 and then allowing Cargo.toml to be treated similarly in #12281. We'd need to be careful in terms of what doors generalizing this might close to us in the future.. Maybe if we just loosened the restriction to .toml? Things might be a little weird with our stance in #45 though maybe with the lack of auto-discovery, this wouldn't be a problem.

Depending on what all was different between files, this could also cause a lot of churn in Cargo.lock.

The alternative Cargo.toml files wouldn't be accessible in published packages.

For some of the use cases, I wonder if features like the following would be better

• Allow specifying a set of supported target platforms in Cargo.toml #6179
• Support [target.'cfg(...)'.lib] sections #12260
• Target configuration for binaries #9208

Or just defining separate packages.

[epage]

Based on the above plus our design principle of having opinionated workflows,. I'm going to propose to the cargo team that we close this.

[ChrisDenton]

I don't feel strongly about this at all but it seem does seem unfortunate that --manifest-path is the only flag where an exact file name is required? Obviously there are a lot of caveats and reasons why using anything but Cargo.toml is bad in the general case but like, what's wrong with wanting to test with Cargo.toml.orig, etc?

Or maybe it should have always been --manifest-directory and not make you type out the redundant Cargo.toml (can't change that now, obviously).