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 #4992 (comment)

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

[samfux84]

Is there any solution for this?

On our universities HPC cluster (with 4000+ users), the home directories are mounted via an automounter script in the path /cluster/home/$USER, which basically makes rust unusable:

sfux@eu-login-11:~$ module load stack/2024-06 rust/1.75.0-bsyu2z5
sfux@eu-login-11:~$ pwd
/cluster/home/sfux
sfux@eu-login-11:~$ cargo init hello
error: Failed to create package `hello` at `/cluster/home/sfux/hello`

Caused by:
  failed to read `/cluster/home/Cargo.toml`

Caused by:
  Permission denied (os error 13)
sfux@eu-login-11:~$

When cargo tries to access /cluster/home/Cargo.toml, then the automounter tries to mount a home directory for the inexistent user "Cargo.toml", which causes cargo to fail creating any new project.

Is there any workaround to make rust usable on systems that use an automounter?

[samfux84]

Could it be a workaround to create an empty Cargo.toml file in $HOME?

sfux@eu-login-13:~$ module load stack/2024-06 rust/1.75.0-bsyu2z5
sfux@eu-login-13:~$ touch Cargo.toml
sfux@eu-login-13:~$ cargo init hello
warning: virtual workspace defaulting to `resolver = "1"` despite one or more workspace members being on edition 2021 which implies `resolver = "2"`
note: to keep the current resolver, specify `workspace.resolver = "1"` in the workspace root's manifest
note: to use the edition 2021 resolver, specify `workspace.resolver = "2"` in the workspace root's manifest
note: for more details see https://doc.rust-lang.org/cargo/reference/resolver.html#resolver-versions
     Created binary (application) package
sfux@eu-login-13:~$ cat Cargo.toml
workspace = { members = ["hello"] }
sfux@eu-login-13:~$