cargo build looks for Cargo.toml in all parent directories

[MatthewHannigan]

This is somewhat related to issue #1423, but for parent dirs, not subdirectories.
This is on macos in case it matters. The problem might be worse if say other users have write access to any parent directories.

$ cargo --version
cargo 0.24.0
$ rustc --version
rustc 1.23.0
$ cd /tmp
$ mkdir -p a/b/c/d/e
$ cd a/b/c/d/e
$ cargo new test-project
     Created library `test-project` project
$ cd test-project/
$ ls
Cargo.toml  src
$ cargo build
   Compiling test-project v0.1.0 (file:///private/tmp/a/b/c/d/e/test-project)
    Finished dev [unoptimized + debuginfo] target(s) in 0.67 secs

$ touch /tmp/Cargo.toml
$ cargo build
error: failed to parse manifest at `/private/tmp/Cargo.toml`

Caused by:
  no `package` section found.`

[steveklabnik]

Isn't this expected behavior?

[MatthewHannigan]

Steve, I don't know. I'm a newb at Rust but it was certainly surprising to me. Isn't there some notion of a root of a project at which cargo would stop searching?

Also note the write problem. If someone else could write a Cargo.toml to some parent dir of yours might that not perturb or compromise your project?

[sfackler]

How would you define the root of the project other than the place with the Cargo.toml?

Who is this person that has write access to directories that you don't trust?

[MatthewHannigan]

1. Defining root -- directory with .git (or .hg?) and src and Cargo.toml perhaps. Or a cargo new option? To be placed in the Cargo.toml. project_root = yes or something like that.
   EDIT -- Found it! By reading the fine manual. Put [workspace] in the Cargo.toml. I don't know whether this is the correct fix but it works. Perhaps [workspace] could be put in the Cargo.toml as default (if --bin) or as an option.

2. Re trust - yes it's a unlkely scenario.

Let me tell you how I got to this point. You may then want to recategorise this as a "out of box experience" anecdote and/or close.

I had some small example rust code - single file examples in the same directory.
I tried to compile one (I think I had been successful before).
The meat of the program was just println!(time::get_time())
On first attempt I got the error error: expected a literal
I found this was caused by not declaring the crate time.
So I added extern crate time; and tried rustc again.
This time I got can't find crate for time
So I ran cargo install time and got the error

   Updating registry `https://github.com/rust-lang/crates.io-index`
  Installing time v0.1.39                                                       
error: specified package has no binaries

Web search for that suggested creating a Cargo.toml file. I made one after reading this doc. It had these lines.

[dependencies]                                
time = "0.1"

Running cargo build got an error no package section found.

So I read up more about cargo and chose to use the cargo new ... command to create a whole project in a subdirectory.

Within that directory I again ran cargo build and got the same error! -- no package section found.

I looked at the Cargo.toml but it did have a package section.

It took me way too long to notice that the Cargo.toml file it mentioned in the error message was the Cargo.toml in the parent directory.

So there's my sorry tale. I'm sure I could have read more docs beforehand but I thought I could do without cargo. And those error messages error: expected a literal and error: specified package has no binaries are particularly opaque.

And the use of a Cargo.toml in a parent directory was entirely unexpected.

[MatthewHannigan]

Postscript: I found the correct form of printing the time is
println!("{:?}", time::get_time());
but it doesn't affect the above story materially.

[EricRahm]

I've run into this issue as well. In my case I'm building a project in automation to be included as a toolchain in our build system. Roughly:

cd $WORKSPACE && git clone project && cd project && cargo build --release

A previous project and/or dependent toolchain left a Cargo.toml file in the $WORKSPACE directory causing my build to fail. For this use case assuming pwd is the root directory make sense. Perhaps this could be added as a flag?

One other option suggested was adding a package workspace directory in my Cargo.toml could help, but as this is in automation that doesn't really make sense.

[alexcrichton]

This is indeed currently working as intended in Cargo (since 1.0!)

It may be possible to add a flag or configuration that tells Cargo to not do this, but that'd be a separate issue and should probably be in its own dedicated issue as well

[deg4uss3r]

Was there ever an issue/PR put in to switch this behavior behind a config option? We would love to have that for CLIs like cargo-outdated.