5 ms·

> 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 r

by gspr 5y ago

> 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.

zaarn 5y ago
>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).
- orlp 5y ago
  https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
  - zaarn 5y ago
    That's basically what is suggested above, except more integrated, and basically what GP wanted.
pohl 5y ago
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.
- pjmlp 5y ago
  Same can be told about npm, and I hardly see anyone jump of joy regarding it.
  - jrockway 5y ago
    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.)
    - gspr 5y ago
      > 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.

by gspr 5y ago

zaarn 5y ago

>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).

orlp 5y ago
https://doc.rust-lang.org/cargo/commands/cargo-vendor.html https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
- zaarn 5y ago
  That's basically what is suggested above, except more integrated, and basically what GP wanted.

pohl 5y ago

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.

pjmlp 5y ago
Same can be told about npm, and I hardly see anyone jump of joy regarding it.
- jrockway 5y ago
  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.)
  - gspr 5y ago
    > 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.