I've got a crate with a mess like this:

[dependencies]
memchr = "0.1"
quickcheck = { version = "0.2", optional = true }
itertools = { version = "0.4", optional = true }
odds = { version = "0.2", optional = true }
jetscii = {version = "0.3", features= ["unstable"], optional = true }

[dev-dependencies]
regex = "0.1"
itertools = "0.4"
odds = "0.2"

custom_derive = "0.1"
newtype_derive = "0.1"
rand = "0.3.10"

<stdin>:1:2: 1:3 error: unknown start of token: \\
<stdin>:1 C\:> setx path \"%path%;C:\path\to\cargo-graph\binary\"
           ^
thread '<unnamed>' panicked at 'Box<Any>', ../src/libsyntax/parse/lexer/mod.rs:1227
Could not document `cargo-graph`.

Previously, cargo graph would merge all versions of a crate into a single node. However, a dependency graph may include multiple versions of the same crate. It is helpful to have a graph that shows which dependencies bring in an older version of a crate.

Now, instead of using only the name to identify a node in the graph, we use both the name and the version. For the project's direct dependencies, we take the version from the [root] table in Cargo.lock.

Since Cargo.toml doesn't contain the actual version used for dependencies, we can't properly initialize the list of dependencies while parsing Cargo.toml. However, Cargo.toml contains one piece of information that isn't in Cargo.lock: the kind of dependency (build, dev or optional). Instead of using a single Dep struct to store the information from both sources, we now use two structs: DeclaredDep, which represents a dependency declared in Cargo.toml, and ResolvedDep, which represents a resolved dependency in Cargo.lock.

The kind of dependency on a ResolvedDep is propagated to indirect dependencies once the whole graph has been filled. Instead of having a single kind on a ResolvedDep, we use a set of flags so that we assign the correct kind when an indirect dependency is used through direct dependencies with different kinds.

When --include-versions is not passed, nodes for crates with multiple versions in the graph will show the version anyway, in order to disambiguate the nodes that would otherwise have the same text.

Closes #27. Closes #28.

I investigated #24 and I found 2 problems:

• When an orphan node was detected and removed, the indexes in the nodes vector changed for all the nodes after it, but the edges were not updated to match new indexes. It then triggered an out-of-bound panic on the next loop execution. Also, edges originating from the removed node were not removed.
• The preliminary bound check was incorrect and did not remove edges pointing at/originating from 1-past the number of nodes, resulting in an out-of-bound panic in the next loop.

When using workspaces, Cargo.toml's [root] is basically just backwards compatibility and no longer points to master crate. This makes graph incomplete, cause it doesn't contain all crates from the workspace.

Full description of an issue can be found here: https://github.com/rust-lang/cargo/issues/3203

Follow up on #15. Graph with deps look nice. Without dev-deps, it panics:

Node N14 doesn't exist, but it tries to add the edge N3 -> N14. N3 is memchr so the only thing it should link to is libc.

$ RUST_BACKTRACE=1 ~/bin/cargo-graph graph 
thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:367
stack backtrace:
   1:     0x5599470a91a0 - sys::backtrace::tracing::imp::write::h2121cc3fd481a5bfxXt
   2:     0x5599470ab565 - panicking::log_panic::_<closure>::closure.41181
   3:     0x5599470aafe0 - panicking::log_panic::h274f0982d2d31f5d62x
   4:     0x55994709ed93 - sys_common::unwind::begin_unwind_inner::ha197e3d3bf39738b4Ps
   5:     0x55994709f128 - sys_common::unwind::begin_unwind_fmt::h377d567d53530218aPs
   6:     0x5599470a8801 - rust_begin_unwind
   7:     0x5599470d7d6f - panicking::panic_fmt::hd08c5b6fdb7b10daxuL
   8:     0x5599470d8048 - panicking::panic::h588d88296fb1b1954sL
   9:     0x559946f4f942 - option::_<impl>::unwrap::unwrap::h16263530560132818147
                        at ../src/libcore/macros.rs:20
  10:     0x559946f4ee67 - graph::_<impl>::label::h10115180723912119468
                        at src/graph.rs:17
  11:     0x559946f490ff - graph::_<impl>::render_to::h7564755762930757336
                        at src/graph.rs:142
  12:     0x559946f43159 - execute::h2d7033028e348fb8ogc
                        at src/main.rs:390
  13:     0x559946f3d2ed - main::h75e0a80141ee56f0Ifc
                        at src/main.rs:378
  14:     0x5599470aad84 - sys_common::unwind::try::try_fn::h1190371136003024825
  15:     0x5599470a8648 - __rust_try
  16:     0x5599470aaa26 - rt::lang_start::h63ca0c2ab43f095fe0x
  17:     0x559946f43399 - main
  18:     0x7f94da5bdb44 - __libc_start_main
  19:     0x559946f30c38 - <unknown>
  20:                0x0 - <unknown>
digraph dependencies {
        N0[label="twoway"];
        N1[label="itertools"];
        N2[label="jetscii"];
        N3[label="memchr"];
        N4[label="odds"];
        N5[label="quickcheck"];
        N6[label="rand"];
        N7[label="advapi32-sys"];
        N8[label="winapi"];
        N9[label="winapi-build"];
        N10[label="libc"];
        N11[label="log"];
        N12[label="unreachable"];
        N13[label="void"];
        N0 -> N1[label=""];
        N0 -> N2[label=""];
        N0 -> N3[label=""];
        N0 -> N4[label=""];
        N0 -> N5[label=""];
        N0 -> N6[label=""];
        N0 -> N7[label=""];
        N0 -> N8[label=""];
        N0 -> N9[label=""];
        N3 -> N14

Trying to update the dependency graph for https://github.com/PistonDevelopers/opengl_graphics

$ cargo graph --optional-deps false --dev-deps false | dot -Tpng > Cargo.png

This gets a graph where vecmath has wrong dependencies:

The only dependency of "vecmath" is "piston-float", but the graph shows these:

• kernel32-sys
• bitflags
• num
• winapi-build

Don't know if you're still working on this, but I hope you are! It looks like Cargo 1.41 changed up the format of the Cargo.lock file, so now this only outputs error: No root table found for toml file. If it's an easy fix I might be able to make a PR for it.

Thanks!

Hi! I wanted to generate a dependency graph for mn mnemonic but cargo-graph gives me the error

File { fd: 3, path: "/home/swym/tmp/mnemonic/Cargo.toml", read: true, write: false }:11:1-11:8 duplicate key: version

I failed to find a duplicate version key manually and also tomlcheck confirms that Cargo.lock seems fine.

gh won't let me attach Cargo.lock but you should be able to reproduce by git cloning mnemonic...

The version of cargo-graph published on crates.io doesn't incorporate the fix for issue #40. Bump the version number so that cargo install can automatically pull in the fixed version.

While reviewing the dependencies of a project, it is quite common to review the details of a certain package on crates.io.

Graphviz can render hyperlinks on nodes and edges when the output is svg, postscript or map. This change adds a href property on the nodes in the dot file. The url for the href is currently set to https://crates.io/(?P<package>.*)(/(?P<version>.*))?