--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).

[epage]

Part of this comes down to use cases. For most I've seen, its to cover for missing features of Cargo and we'd like want to focus on those. If there are more, let us know!

For some context, this isn't just a superficial change in the CLI and we're done.

As of right now, we track path sources by directory, preventing us from being able to convert from that back to a non-canonical Cargo.toml. We already need to partially address this for #12207 as something kind of like our Source ID ends up in the user-facing Package Id Spec. In working on that, it'll help us have an idea of how well we can also support pointing directly to a file and not just the directory more generally.

That involves the infrastructure side. The next part is if we should allow having dependencies to a Cargo.toml.something. We'd need to make sure the above does not accidentally affect this. For #12207, we've deferred that out. If we wanted it, we'd likely want to wait for that so we can develop it in lockstep. Supporting this for dependencies seems backwards. Not supporting this for dependencies seems inconsistent.

We'd also need to consider how we tell the formats apart. Right now,, the rules are

• No extension or .rs: cargo script
• Cargo.toml: manifest

I'd really not like to get into sniffing the file contents and guessing as a small bug could have very strange results. We'd need to define what we use to recognize something is a regular manifest format.

[ChrisDenton]

Fair enough.