Put Searching Parent Directories for `Cargo.toml` Behind Logical Gate

[deg4uss3r]

Describe the problem you are trying to solve In cargo-outdated we are seeing an issue (we build the project under /tmp) where if there's a cargo.toml that was moved to /tmp/ cargo build will fail.

Describe the solution you'd like Either a seperate find_root() (link)that we can trigger from workspace::new(), or a config option to stop the function from crawling upwards (link) in the directory ancestors.

Notes This was mentioned in https://github.com/rust-lang/cargo/issues/4992#issuecomment-401129850

I understand this is necessary for cargo and it's the intended function; however, using cargo as an API there should be a way to avoid this :)

[deg4uss3r]

Just curious if we could chat about this issue? I’m happy to put in a PR :)

[TrondKjeldas]

Just want to mention another situation where this “feature” can cause problems.

When running cargo in a directory which resides on an NFS mount which is auto mounted, where e.g. /net is the automounter top level.

Cargo searches parent directories until it reaches /net/Cargo.toml, which causes automounter to try to find an NFS export for this name. Depending on the config this can take quite some time before it times out.

[goertzenator]

This also caused me problems when bringing up rust-analyzer in my dev environment: I was guided to create a Cargo.toml at the root of my large polyglot project so that rust-analyzer could find my crates. This of course moved where the expected Cargo.locks were being generated.

It is surprising to me that something in the Rust ecosystem is so vulnerable to environment side-effects when Rust the language is so very tight about that sort of thing.

[epage]

rust-lang/rfcs#3279 is also related to this