It’s probably just misleading to people who don’t understand the implied semantic (which you describe above). That seems like a fair (if minor) criticism. I certainly think there’s a lot of validity in listing the manually managed dependencies, but maybe it would be clearer if we called them “manually managed dependencies” rather than simply “dependencies”?

> The reason that projects usually only list the non-Rust deps in their readme is because these need to be installed manually by the user in order to build or run the piece of software in question.

I understand that. It's almost spelled out in my comment. But the ones that can be automatically installed by Cargo are still dependencies.

> There would be no point in listing all direct and indirect crates that a project depends on in the readme, since that list is already in Cargo.lock anyway which is meant to also be committed.

I know. But this should at the very least be acknowledged.

> Really don’t see any reason for this particular objection.

It's entirely reasonable for someone not to want tooling to automatically grab dependencies from the internet. Such people need to know which dependencies they need to provide.

I see no reason why library authors should be expected to document this when the actual source of truth — the Cargo.toml file — is sitting right there and will never be wrong. If you want to see the transitive dependencies, all you need is to run "cargo tree".

Both crates.io and lib.rs surface this automatically right there on the crate's page.

The rust "culture" on transitive dependencies is actually laudably transparent: it's built right into the tools.

Same can be told about npm, and I hardly see anyone jump of joy regarding it.

I mean, the number of dependencies a node project uses doesn't really affect me. If they have 1 or if they have 1 million, it's the same "npm install" command.

I personally like to keep third-party dependencies as minimal as possible, mostly to avoid getting 8 emails a day from dependabot telling me that a dependency of a dependency of a dependency has a regex denial of service attack and some dependency in the middle has a massive breaking change that prevents another dependency from being upgraded to include the fix. (Nevermind that I'm using it on the frontend, so if a user picks a bad regex they will slow down their own browser and nobody else's.)

> If they have 1 or if they have 1 million, it's the same "npm install" command.

Only if you accept one single, unflexible way of installing the software.

>Such people need to know which dependencies they need to provide.

Cargo.lock specifies exactly which dependencies are required and in which version (down to git commit hashes and checksums). You can parse that file, way less error prone that doing it by hand (you can probably even fully automate the process of checking out the dependency repos).

That's basically what is suggested above, except more integrated, and basically what GP wanted.

It matters to people who are installing this software on non-internet connected machines. Granted, that's a niche these days, but there is a reason Node never took off in that space.

Unlike Node, here you can just copy the binary over. Rust binaries are statically-linked by default (though C dependencies can complicate that).

Rust binaries aren't statically linked by default, but all of the rust code in the binary is.

Rust isn’t statically compiled, you can make it so, but it isn’t by default, it depends on the libc you link against, on Linux it is glibc.

Regardless: you’re right in some regards. Cargo vendor exits, so you can ship your code dependencies alongside your own code.

These are called “prerequisites” in the software industry.