How to handle non-registry dependencies?

[epage]

Currently we show all dependencies as name@req. That is less meaningful for path and git dependencies. How should we handle these?

[Rustin170506]

How about we print the source ID there? For example:

cargo-information
A cargo subcommand to show information about crates.
version: 0.4.1 (from ./)
license: MIT
rust-version: 1.73
repository: https://github.com/hi-rustin/cargo-information
features:
  default          = []
  vendored-openssl = [cargo/vendored-openssl]
dependencies:
  anstyle@1.0.4
  anyhow@1.0.79
  cargo@0.76.0
  cargo-credential@0.4.1
  cargo-util@0.2.8
  clap@* (https://github.com/clap-rs/clap)
  color-print@0.3.5
  crates-io@0.39.1
  pathdiff@0.2.1
  semver@1.0.21

We print the git repo link here.

[Rustin170506]

Another example:

cargo
Cargo, a package manager for Rust.
version: 0.78.0 (from ./)
license: MIT OR Apache-2.0
rust-version: 1.75.0
documentation: https://docs.rs/cargo
homepage: https://doc.rust-lang.org/cargo/index.html
repository: https://github.com/rust-lang/cargo
features:
  all-static       = [vendored-openssl, curl/static-curl, curl/force-system-lib-on-osx, vendored-libgit2]
  vendored-openssl = [openssl/vendored]
  vendored-libgit2 = [libgit2-sys/vendored]
  openssl          = [dep:openssl]
dependencies:
  annotate-snippets@0.10.1
  anstream@0.6.5
  anstyle@1.0.4
  anyhow@1.0.79
  base64@0.21.5
  bytesize@1.3
  cargo-credential@0.4.2 (/Volumes/t7/code/cargo/credential/cargo-credential)
  cargo-platform@0.1.4 (/Volumes/t7/code/cargo/crates/cargo-platform)
  cargo-util@0.2.6 (/Volumes/t7/code/cargo/crates/cargo-util)
  cargo-util-schemas@0.2.0 (/Volumes/t7/code/cargo/crates/cargo-util-schemas)
  clap@4.4.12
  color-print@0.3.5
  crates-io@0.40.0 (/Volumes/t7/code/cargo/crates/crates-io)

[Rustin170506]

I should use the pretty_source here to print a better local path.

[epage]

If its not terrible to do, I think we should prefer relative paths, rather than absolute paths.

I also wonder if we should reserve showing all dependencies for a --verbose. Maybe we only show public dependencies by default? Its still an unstable feature but something for us to keep in mind as we work to stabilize both of these.

[Rustin170506]

I also wonder if we should reserve showing all dependencies for a --verbose. Maybe we only show public dependencies by default?

How about we show all the dependencies and only show the dev-dependencies and build-dependencies for a --verbose. I guess checking its dependencies before you use it in your project would always be considered.

[epage]

Moved this to #23 since handling of non-registry dependencies is independent of this

[Rustin170506]

closed by #100