document external cargo subcommand PATH precedence

[eval-exec]

Problem

I have encountered an issue with the cargo nextest subcommand where it does not select the expected subcommand's version.

Steps

Here are the details of the problem:

1. I have cargo-nextest in my PATH, located at /nix/store/3yl7vgm2qkp7skr5gskbfd457f6g43cg-cargo-nextest-0.9.66/bin/cargo-nextest, and its version is 0.9.66.

bash-5.2$ which cargo-nextest
/nix/store/3yl7vgm2qkp7skr5gskbfd457f6g43cg-cargo-nextest-0.9.66/bin/cargo-nextest

3. Additionally, I have cargo-nextest installed in ~/.cargo/bin, and its version is 0.9.59.

bash-5.2$ ~/.cargo/bin/cargo-nextest --version
cargo-nextest 0.9.59

4. Running ~/.cargo/bin/cargo-nextest --version confirms that the version installed in ~/.cargo/bin is indeed 0.9.59.

5. However, when I execute cargo nextest --version, it incorrectly selects version 0.9.59 from ~/.cargo/bin, instead of the desired version 0.9.66 from /nix/store/3yl7vgm2qkp7skr5gskbfd457f6g43cg-cargo-nextest-0.9.66/bin/cargo-nextest.

bash-5.2$ cargo nextest --version
cargo-nextest-nextest 0.9.59

This behavior seems inconsistent and unexpected. It would be helpful if the cargo command could prioritize the version in the path /nix/store/3yl7vgm2qkp7skr5gskbfd457f6g43cg-cargo-nextest-0.9.66/bin when invoking the cargo nextest subcommand.

Thank you for your attention to this issue, and please let me know if you need any further information to reproduce or investigate the problem.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.72.1 (103a7ff2e 2023-08-15)
release: 1.72.1
commit-hash: 103a7ff2ee7678d34f34d778614c5eb2525ae9de
commit-date: 2023-08-15
host: x86_64-unknown-linux-gnu
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 8.1.2-DEV (sys:0.4.63+curl-8.1.2 vendored ssl:OpenSSL/1.1.1u)
ssl: OpenSSL 1.1.1u  30 May 2023
os: NixOS 24.5.0 [64-bit]

[linyihai]

Hello,

cargo-nextest is not the cargo built-in command and this issue may not be related to cargo.

And I see you desired cargo is in /nix/store/..., is there something like .env to activate it ?

[epage]

This is a concern not with cargo-nextest but with how third-party subcommands are loaded.

On mobile so can't look everything up but cargo intentionally prefers the copy of packages it has installed. You can customize this by putting cargo's bin directory in PATH. If cargo sees it there, it will respect the users precedence.

[ehuss]

Thanks for the report! As @epage mentioned, I believe cargo looks at PATH to determine the priority, so you can put ~/.cargo/bin later in the PATH. Closing as a duplicate of #11020 and #6507.

[weihanglo]

Have we documented this behavior in The Cargo Book? If not, I would like to propose this as a documentation issue.

cargo/src/bin/cargo/main.rs

Lines 247 to 270 in 363a2d1

	fn search_directories(config: &Config) -> Vec<PathBuf> {
	let mut path_dirs = if let Some(val) = config.get_env_os("PATH") {
	env::split_paths(&val).collect()
	} else {
	vec![]
	};
	let home_bin = config.home().clone().into_path_unlocked().join("bin");
	// If any of that PATH elements contains `home_bin`, do not
	// add it again. This is so that the users can control priority
	// of it using PATH, while preserving the historical
	// behavior of preferring it over system global directories even
	// when not in PATH at all.
	// See https://github.com/rust-lang/cargo/issues/11020 for details.
	//
	// Note: `p == home_bin` will ignore trailing slash, but we don't
	// `canonicalize` the paths.
	if !path_dirs.iter().any(|p| p == &home_bin) {
	path_dirs.insert(0, home_bin);
	};
	path_dirs
	}

[ehuss]

Updating the documentation sounds good to me!

[linyihai]

@rustbot claim

I plan to add this behavior in the custom-subcommands section. (a note block in the last )