kbknapp / cargo-outdated

A cargo subcommand for displaying when Rust dependencies are out of date

Hi there 👋

Some Stats

Top Languages

cargo-outdated's Issues

Provide option to check build dependencies as well

Or perhaps make it the default?

Provide an option to loop through all workspace members

Thanks to #58, this is possible if the crate has a virtual manifest. However, it would be useful to trigger this behavior from crates without a virtual manifest as well.

Remove unwraps

There's a lot of unwraps...now that it works most of them should be removed.

error: permission denied

Cargo outdated errors on Windows with this output:

Parsing Cargo.lock...Done
Setting up temp space...Done
Checking for SemVer compatible updates...Done
Parsing the results...Done
Cleaning up temp semver files...Done
error: permission denied
Creating temp space for latest versions...error: third party subcommand `cargo-outdated.exe` exited unsuccessfully

To learn more, run the command again with --verbose.

Exit Codes

Hey there,
I was thinking about using this in CI. Would it be possible to add an argument so that cargo outdated exits with 1?

Thank you so much

Consider using cargo_metadata instead of cargo crate

It take too long to compile cargo. An alternative is to use cargo_metadata, which offers an api over the cargo metadata command.

Support JSON output format

Print out the dependency tree to a JSON

Inconsistent output caused by `--root` parameter

Say the following dependency tree is generated:

hello_world -> hyper (0.10.12) -> [url, unicase, ...]

...and cargo outdated -r hyper -d 0 is executed against the package

Actual output:

All dependencies are up to date, yay!

Expected output:

Name   Project Ver  SemVer Compat  Latest Ver
hyper     0.10.12        --          0.11.2

Unable to update registry behind proxy

cargo outdated command failed in case of connection through proxy server:

error: failed to load source for a dependency on byteorder
Caused by:
Unable to update registry https://github.com/rust-lang/crates.io-index
Caused by:
failed to fetch https://github.com/rust-lang/crates.io-index
Caused by:
[12/-16] proxy authentication required, but no callback provided

Loop through all workspace members if executed against a virtual manifest

Mentioned here by @Keats.

And the suggested format is:

site
================
Name          Current  Compat  Latest    Kind         Platform
clap          2.20.0   2.20.5  2.26.0    Normal       ---

rendering
================
Name          Current  Compat  Latest    Kind         Platform
clap          2.20.0   2.20.5  2.26.0    Normal       ---

Error when the package.name is different from the lib.name

error: failed to parse manifest at %TEMP%\...
Caused by:
can't find library sciter, rename file to src/lib.rs or specify lib.path

As I see, this error is coming from cargo/targets.rs. So I am not sure whether this error is in cargo-outdated or in cargo itself.

And yes, path = "src/lib.rs" resolves it. Partially, because it does not show updates, just prints

All dependencies are up to date, yay!

despite lazy_statis is 0.2 in toml and 1.0 at crates.io. And if I create a new --bin project and test it, cargo outdated shows its update (lazy_static 0.2.11 --- 1.0.0). Strange.

Project: https://github.com/sciter-sdk/rust-sciter.

env:

rustc 1.22.1
cargo 0.23.0
cargo-outdated v0.7.0

What does "RM" mean in the output?

Name                                   Project Ver     SemVer Compat  Latest Ver
aho-corasick->memchr                      0.1.11            RM            RM

Might be nice to have this explained somewhere.

1.(Y+1).Z is misreported as incompatible

I haven’t actually tested it myself, but from the README:

    Name                 Project Ver  SemVer Compat  Latest Ver
    clap                    1.2.3        1.2.5         1.4.7

1.4.7 is compatible with 1.2.3 according to SemVer. Only before 1.0.0 are all bets off for minor version number increments.

Outputs "up to date" when dependency has new version available

cargo outdated shows that all dependencies are up to date when they are clearly not.

Here's an example:

$ cat Cargo.toml 
[package]
name = "outdated_test"
version = "0.1.0"
authors = ["Dabo Ross <[email protected]>"]

[dependencies]
pistoncore-window = "0.8"
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading pistoncore-window v0.8.0
 Downloading pistoncore-input v0.4.0
   Compiling rustc-serialize v0.3.16
   Compiling bitflags v0.3.2
   Compiling piston-float v0.1.0
   Compiling shader_version v0.2.1
   Compiling piston-viewport v0.1.0
   Compiling pistoncore-input v0.4.0
   Compiling pistoncore-window v0.8.0
   Compiling outdated_test v0.1.0 (file:///home/daboross/outdated_test)
$ cargo outdated
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
All dependencies are up to date, yay!
$ cargo search "pistoncore-window"
    Updating registry `https://github.com/rust-lang/crates.io-index`
pistoncore-window (0.9.1)    A library for window abstraction

As you can see, a new version of pistoncore-window (0.9.1) is clearly available, but cargo outdated doesn't show this.

Error messages are not shown without `-v`

Hard to distinguish direct dependencies from indirect dependencies

Cargo.toml

[package]
authors = ["Jake Goulding <[email protected]>"]
name = "top-crates"
version = "0.1.0"

[dependencies]
cargo = "0.19.0"
hyper = "0.10.9"
hyper-native-tls = "0.2.2"
lazy_static = "0.2.8"
serde = "1.0.1"
serde_derive = "1.0.1"
serde_json = "1.0.0"
toml = "0.4.0"

Cargo.lock

A snippet of the output looks like this:

cargo                                       0.19.0   ---      0.20.0   Normal  ---
cargo->chrono                               0.2.25   ---      Removed  Normal  ---
cargo->toml                                 0.3.2    ---      0.4.5    Normal  ---
chrono->num                                 0.1.40   ---      Removed  Normal  ---
cmake->gcc                                  0.3.51   0.3.53   0.3.53   Normal  ---

As I read through this output, I'm surprised by the appearance of chrono and cmake on the left hand side — those aren't dependencies of mine. After thinking about it for a while, I realize that they are transitive dependencies.

Preparing this report, I see that there's a --depth parameter that I can provide, and setting it to zero is probably the right solution for my use case most of the time.

I do think being able to tell all of my outdated dependencies is a great feature, but updating those requires considerably more effort than updating my direct dependencies.

I think that being able to visually distinguish direct dependencies from indirect would be nice, although I guess that's anything without a ->. There's just something about the current display that's overwhelming.

I don't know that anything I've said here is useful or actionable. Consider this unsolicited user feedback and feel free to close it as you see fit 😸

cargo outdated errors if a package removed a feature in a newer version

To reproduce:

Cargo.toml:

[package]
name = "dep-test"
version = "0.1.0"

[dependencies]
handlebars = { version = "0.25", features = ["serde_type"] }

$ cargo outdated -R
error: Package `handlebars v0.29.1` does not have these features: `serde_type`

Fails to run 'cargo update'

When I run cargo outdated in a project with at least one dependency, it fails with the following error:

Checking for SemVer compatible updates...error: Failed to run 'cargo update' with error 'did not exit successfully'

When I run cargo update, ~/.cargo/bin/cargo update, or ~/.rustup/toolchains/nightly-x86_64-pc-windows-msvc/bin/cargo update, they're successful.

Check for wildcard dependencies recursively

Hi there!

I initially asked this question on SO. The user "Pyfish" wrote a script to do some rudimentary checking (see the his/her answer). I thought it would be awesome to have something like that integrated in a tool and I think your tool comes closest to what I want.

So my feature request: check if there is a wildcard dependency in the dependency graph and emit a warning for every wildcard found.

output varies from run to run, and also misses things

I'm running cargo outdated against https://github.com/dimbleby/iron-hmac/tree/update-dependencies (at 3fea6b1e). Here's an example in which an intermediate run of cargo outdated -w causes cargo outdated to change its mind:

$ cargo outdated
Name                      Project  Compat  Latest   Kind    Platform
----                      -------  ------  ------   ----    --------
iron                      0.5.1    ---     0.6.0    Normal  ---
iron->conduit-mime-types  0.7.3    ---     Removed  Normal  ---
iron->error               0.1.9    ---     Removed  Normal  ---
iron->lazy_static         0.2.9    ---     Removed  Normal  ---

$ cargo outdated -w
iron-hmac
================
Name                Project  Compat  Latest   Kind    Platform
----                -------  ------  ------   ----    --------
conduit-mime-types  0.7.3    ---     Removed  Normal  ---
error               0.1.9    ---     Removed  Normal  ---
iron                0.5.1    ---     0.6.0    Normal  ---
lazy_static         0.2.9    ---     Removed  Normal  ---


$ cargo outdated
Name                                 Project  Compat  Latest   Kind    Platform
----                                 -------  ------  ------   ----    --------
conduit-mime-types->rustc-serialize  0.3.24   ---     Removed  Normal  ---
error->traitobject                   0.1.0    ---     Removed  Normal  ---
error->typeable                      0.1.2    ---     Removed  Normal  ---
iron                                 0.5.1    ---     0.6.0    Normal  ---
iron->conduit-mime-types             0.7.3    ---     Removed  Normal  ---
iron->error                          0.1.9    ---     Removed  Normal  ---
iron->lazy_static                    0.2.9    ---     Removed  Normal  ---

All of the above miss various other things that are also outdated. eg hyper was never mentioned, but there's definitely a dependency on an old version:

$ grep "\"hyper " Cargo.lock
 "hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",
 "hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",
 "hyper 0.10.13 (registry+https://github.com/rust-lang/crates.io-index)",
 "hyper 0.11.6 (registry+https://github.com/rust-lang/crates.io-index)",

I'm at version 0.6.3:

$ cargo outdated --version
cargo-outdated v0.6.3

Support tree-like output format

Print out a tree, like cargo-tree

It may be better to have another intermediate struct so that trees, JSONs can be built based on it.

Segmentation fault for project with private ssh dependencies

Hi,
It seems that private dependencies with an ssh url cause a segmentation fault. I thought private dependencies wasn't supported but I checked with https urls and it works fine.

[dependencies]
dummy1 = { git="ssh://[email protected]/klefevre/dummy.git" } // make crash cargo-outdated
dummy2 = { git="https://github.com/klefevre/dummy.git" } // works

"Latest Ver" shows an older version

Cargo.toml:

[dependencies]
clap = "2.19.0"

cargo update; cargo outdated:

    Updating registry `https://github.com/rust-lang/crates.io-index`
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:

    Name        Project Ver  SemVer Compat  Latest Ver
    clap           2.20.0         --          2.19.3
    clap->libc     0.2.18         --          0.2.20

Default to only showing direct dependencies

It's been mentioned in #51 and in rust-lang/cargo#4309 that the default behaviour should be to limit the output the direct dependencies. Since cargo-outdated has already a -d flag, it should be as simple as defaulting it to 1

Support cargo workspaces

It would be nice to provide a flag to view outdated dependencies for the entire workspace.

Panics on gstreamer-rs workspace "BUG: update() must be called before query()"

Clone the repository at https://github.com/sdroege/gstreamer-rs, run cargo update in the root and then run cargo outdated. It fails like below.

This is with cargo 0.22 and cargo outdated 0.6.0.

$ env RUST_BACKTRACE=1 cargo outdated -w
thread 'main' panicked at 'BUG: update() must be called before query()', /checkout/src/libcore/option.rs:819:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:71
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:381
   2: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:397
             at /checkout/src/libstd/panicking.rs:611
   3: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:572
   4: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:522
   5: core::panicking::panic_fmt
             at /checkout/src/libstd/panicking.rs:498
   6: core::option::expect_failed
             at /checkout/src/libcore/option.rs:819
   7: <cargo::sources::git::source::GitSource<'cfg> as cargo::core::registry::Registry>::query
   8: cargo::core::registry::Registry::query_vec
   9: cargo_outdated::cargo_ops::temp_project::TempProject::find_update
  10: cargo_outdated::cargo_ops::temp_project::TempProject::update_version_and_feature
  11: cargo_outdated::execute
  12: cargo_outdated::main
  13: main
  14: __libc_start_main
  15: _start

thread 'main' has overflowed its stack

This happens whenever I run cargo-outdated in the Rust repository's src directory.

Rust 1.20.

`--exit-code` and `--color` do not work

Fails to build with debug feature

When I try to build with the debug feature, the build fails with the following errors:

$ cargo build --features debug
   Compiling cargo-outdated v0.5.1 (file:///C:/Users/kraaimx/src/cargo-outdated)
error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
   --> src\macros.rs:17:50
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                                                    ^^^^ Maybe a missing `extern crate term;`?
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
152 | /         debug!(
153 | |             config,
154 | |             "UPDATE, self: {:?}, key: {:?}, status: {:?}\n",
155 | |             self_pkg.package_id(),
156 | |             pkg_status_key,
157 | |             pkg_status
158 | |         );
    | |__________- in this macro invocation

error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
   --> src\macros.rs:17:50
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                                                    ^^^^ Maybe a missing `extern crate term;`?
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
165 | /         debug!(
166 | |             config,
167 | |             "LOOP, parent: {:?}, self: {:?}, compat: {:?}, latest: {:?}\n",
168 | |             parent,
...   |
171 | |             latest_pkg
172 | |         );
    | |__________- in this macro invocation

error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
   --> src\macros.rs:17:50
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                                                    ^^^^ Maybe a missing `extern crate term;`?
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
202 | /             debug!(
203 | |                 config,
204 | |                 "NEXT, next_self: {:?}, next_compat: {:?}, next_latest: {:?}\n",
205 | |                 next_self,
206 | |                 next_compat,
207 | |                 next_latest
208 | |             );
    | |______________- in this macro invocation

error[E0433]: failed to resolve. Maybe a missing `extern crate term;`?
   --> src\macros.rs:14:41
    |
14  |         $config.shell().say($message, ::term::color::WHITE)?
    |                                         ^^^^ Maybe a missing `extern crate term;`?
    |
   ::: src\main.rs
    |
241 |     debug!(config, format!("options: {:?}", options));
    |     -------------------------------------------------- in this macro invocation

error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
   --> src\macros.rs:14:25
    |
14  |         $config.shell().say($message, ::term::color::WHITE)?
    |                         ^^^
    |
   ::: src\main.rs
    |
241 |     debug!(config, format!("options: {:?}", options));
    |     -------------------------------------------------- in this macro invocation

error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
   --> src\macros.rs:17:25
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                           ^^^
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
152 | /         debug!(
153 | |             config,
154 | |             "UPDATE, self: {:?}, key: {:?}, status: {:?}\n",
155 | |             self_pkg.package_id(),
156 | |             pkg_status_key,
157 | |             pkg_status
158 | |         );
    | |__________- in this macro invocation

error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
   --> src\macros.rs:17:25
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                           ^^^
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
165 | /         debug!(
166 | |             config,
167 | |             "LOOP, parent: {:?}, self: {:?}, compat: {:?}, latest: {:?}\n",
168 | |             parent,
...   |
171 | |             latest_pkg
172 | |         );
    | |__________- in this macro invocation

error[E0599]: no method named `say` found for type `std::cell::RefMut<'_, cargo::core::Shell>` in the current scope
   --> src\macros.rs:17:25
    |
17  |           $config.shell().say(format!($($arg)*), ::term::color::WHITE)?
    |                           ^^^
    |
   ::: src\cargo_ops\elaborate_workspace.rs
    |
202 | /             debug!(
203 | |                 config,
204 | |                 "NEXT, next_self: {:?}, next_compat: {:?}, next_latest: {:?}\n",
205 | |                 next_self,
206 | |                 next_compat,
207 | |                 next_latest
208 | |             );
    | |______________- in this macro invocation

error: aborting due to 8 previous errors

error: Could not compile `cargo-outdated`.

To learn more, run the command again with --verbose.

doesn't work when dependency is in path

$ cargo outdated
error: Failed to run 'cargo update' with error 'did not exit successfully'

I saw this with c-ares.

I believe the difficulty is dealing with this: cargo outdated copies my Cargo.toml into a temporary directory but does not copy c-ares-sys/Cargo.toml. That's why cargo update fails.

Yanked packages cause "no matching version" error

The package quickcheck version 0.4.2 is yanked which causes error:

error: no matching version `^0.4.2` found for package `quickcheck` (required by `dummylib`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.4.1, 0.4.0, 0.3.2, ...

Example Cargo.toml:

[package]
name = "dummybin"

[dependencies]
dummylib = { path = "../dummylib" }

[dev-dependencies]
dummylib = { path = "../dummylib", features = ["quickcheck"] }

$ cargo outdated
warning: Feature quickcheck of package dummylib has been obsolete in version 0.1.0
warning: Feature quickcheck of package dummylib has been obsolete in version 0.1.0
error: no matching version `^0.4.2` found for package `quickcheck` (required by `dummylib`)
location searched: registry https://github.com/rust-lang/crates.io-index
versions found: 0.4.1, 0.4.0, 0.3.2, ...

The "feature has been obsolete" warning have their own issue: #100.

Error when a package has multiple occurrences with different specified features

The logic in elaborate_workspace.rs is not feature-aware.

readme: dependency tree out of date

It says there is a dependency on rustc-serialize, which no longer is the case. Perhaps just remove it?

Errors when using patch section of Cargo.toml

Here is an example repository: https://github.com/mehcode/cargo-outdated-bug-patch

---

❯ cargo +nightly outdated
error: Direct dependency reqwest not found for package cargo_outdated_bug

---

This is using the most recent cargo-outdated installed via cargo install cargo-outdated.

❯ rustc --version
rustc 1.21.0 (3b72af97e 2017-10-09)

❯ cargo --version
cargo 0.22.0 (3423351a5 2017-10-06)

Use `docopt` instead of `clap`

Since cargo is using docopt

Colorize output

It would be cool if the output is colorized :)
Here is an idea:

• mark yanked versions with red
• outdated parts with orange (e.g. in 1.2.4 -> 1.3.7 the 3.7 would be orange)
• and up to date parts with green (e.g. in 1.2.4 -> 1.3.7 the 1 would be green)

Consistent failure with the same package

Version: 0.5.1

This Cargo.toml always fail with the following error:

error: no matching package named `pest_derive` found (required by `tera`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: *

Replace `format!()` calls with `Path.join()` to construct PathBuf

Path.join() is slightly faster and more idiomatic. Low priority tho.

#![feature(test)]

extern crate test;

use std::path::{Path, PathBuf};

pub fn format_path() -> PathBuf {
    PathBuf::from(format!("{}/{}", "/etc", "systemd/"))
}

pub fn join_path() -> PathBuf {
    Path::new("/etc").join("systemd/")
}

#[cfg(test)]
mod tests {
    use super::*;
    use test::Bencher;

    #[bench]
    fn bench_format_path(b: &mut Bencher) {
        b.iter(|| format_path());
    }

    #[bench]
    fn bench_join_path(b: &mut Bencher) {
        b.iter(|| join_path());
    }
}

⇒  cargo bench
    Finished release [optimized] target(s) in 0.0 secs
     Running target/release/deps/hello_world-f29c263b9d11d26d

running 2 tests
test tests::bench_format_path ... bench:         118 ns/iter (+/- 14)
test tests::bench_join_path   ... bench:          90 ns/iter (+/- 4)

test result: ok. 0 passed; 0 failed; 0 ignored; 2 measured; 0 filtered out

Add a switch to ignore compatible updates.

It would show only deps with a Latest version which is not compatible with SemVer compat. It could be a good thing for libraries, to improve compatibility with other crates.

False warnings for obsolete features

I have a crate that depends on chrono, diesel, uuid, and serde. These each need certain features enabled in order to work together, e.g. from Crate.toml (simplified):

[dependencies.diesel]
features = [
    "postgres",
    "chrono",
]
version = "0.16.0"

[dependencies.chrono]
features = ["serde"]
version = "0.4"

[dependencies]
serde = "1.0.0"
serde_derive = "1.0.0"
serde_json = "1.0.0"

With cargo-outdated 0.6.2, running cargo outdated on this crate produces the following warnings:

warning: Feature serde of package chrono has been obsolete in version 0.4.0
warning: Feature chrono of package diesel has been obsolete in version 0.16.0
warning: Feature uuid of package diesel has been obsolete in version 0.16.0
warning: Feature serde_json of package diesel has been obsolete in version 0.16.0
warning: Feature uuid of package rocket_contrib has been obsolete in version 0.3.3
warning: Feature serde of package uuid has been obsolete in version 0.5.1

However, removing these features causes the crate to fail to compile. cargo outdated should not be producing these warnings if the feature exists on the target version of the dependency.

Inconsistent output

Running cargo outdated multiple times can produce a different number of outdated dependencies:

$ cargo outdated                             
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:

    Name                     Project Ver  SemVer Compat  Latest Ver
    handlebars->quick-error     0.1.4          --          0.2.2
    quick-error                 0.2.2        0.1.4           --
$ cargo outdated                       
Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:

    Name                     Project Ver  SemVer Compat  Latest Ver
    handlebars->quick-error     0.1.4        0.2.2         0.2.2

The Cargo.* files which produce this output can be found in this gist.

Write test cases

Maybe we could publish some dummy crates so that some proper test cases can be written.

And actually I am still a bit unsure about the behaviour of cargo update in some scenarios, e.g. how it deals with yanked dependencies.

Support checking cargo binaries

It would be nice to have cargo outdated work in the global environment and check for updates on the installed cargo binaries when not in a project directory.

Enable `--all-features` by default

Mentioned here by @SergioBenitez

Provide --manifest-path

Please provide --manifest-path, so I can automate checking with my Makefile in imag.

😄

cargo outdated just says 'RM' for everything.

Here's output from one of my projects (c-ares-resolver):

$ cargo outdated
Name                        Project Ver  SemVer Compat  Latest Ver
bytes->byteorder               1.1.0          RM            RM
bytes->iovec                   0.1.0          RM            RM
conv->custom_derive            0.1.7          RM            RM
dns-parser                     0.7.0          RM            RM
dns-parser->byteorder          0.4.2          RM            RM
dns-parser->matches            0.1.6          RM            RM
dns-parser->quick-error        1.2.0          RM            RM
iovec->libc                    0.2.29         RM            RM
iovec->winapi                  0.2.8          RM            RM
kernel32-sys->winapi           0.2.8          RM            RM
kernel32-sys->winapi-build     0.1.1          RM            RM
magenta->conv                  0.3.3          RM            RM
magenta->magenta-sys           0.1.1          RM            RM
magenta-sys->bitflags          0.7.0          RM            RM
mio->iovec                     0.1.0          RM            RM
mio->kernel32-sys              0.2.2          RM            RM
mio->lazycell                  0.5.1          RM            RM
mio->libc                      0.2.29         RM            RM
mio->log                       0.3.8          RM            RM
mio->magenta                   0.1.1          RM            RM
mio->magenta-sys               0.1.1          RM            RM
mio->miow                      0.2.1          RM            RM
mio->net2                      0.2.30         RM            RM
mio->slab                      0.3.0          RM            RM
mio->winapi                    0.2.8          RM            RM
miow->kernel32-sys             0.2.2          RM            RM
miow->net2                     0.2.30         RM            RM
miow->winapi                   0.2.8          RM            RM
miow->ws2_32-sys               0.2.1          RM            RM
net2->cfg-if                   0.1.2          RM            RM
net2->kernel32-sys             0.2.2          RM            RM
net2->libc                     0.2.29         RM            RM
net2->winapi                   0.2.8          RM            RM
net2->ws2_32-sys               0.2.1          RM            RM
tokio-core                     0.1.9          RM            RM
tokio-core->bytes              0.4.4          RM            RM
tokio-core->futures            0.1.14         RM            RM
tokio-core->iovec              0.1.0          RM            RM
tokio-core->log                0.3.8          RM            RM
tokio-core->mio                0.6.10         RM            RM
tokio-core->scoped-tls         0.1.0          RM            RM
tokio-core->slab               0.3.0          RM            RM
tokio-core->tokio-io           0.1.2          RM            RM
tokio-io->bytes                0.4.4          RM            RM
tokio-io->futures              0.1.14         RM            RM
tokio-io->log                  0.3.8          RM            RM
winapi                         0.2.8          RM            RM
ws2_32-sys                     0.2.1          RM            RM
ws2_32-sys->winapi             0.2.8          RM            RM
ws2_32-sys->winapi-build       0.1.1          RM            RM

#46 already has me covered for "I've no idea what RM even means", this issue says "surely that's not right?"

cargo-outdated reports no SemVer-compat version when there is one

Running the command on my project that has clap 2.24.2 in my Cargo.lock, I get the following output.

Checking for SemVer compatible updates...Done
Checking for the latest updates...Done
The following dependencies have newer versions available:

    Name      Project Ver  SemVer Compat  Latest Ver
    clap         2.24.2         --          2.25.0

I would expect the SemVer Compat column to contain "2.25.0".

Default features are not excluded even if `--features ''` is set

Please publish a crate

This project is cool! Now that cargo install works, if this was published as a crate, we could use cargo install cargo-outdated to install the project.

Support relative path in dependency

This is related to #50.
If we create two local cargo projects under the same working directory foo and bar by running cargo new foo and cargo new bar, and having bar depending on foo by including the following in the Cargo.toml of bar:

[dependencies.foo]
version = "0.1"
path = "../foo"

It will compile successfully using cargo build. cargo outdated will throw an error:

cargo outdated
error: failed to load source for a dependency on `foo`

Caused by:
  Unable to update file:///tmp/foo

Caused by:
  failed to read `/tmp/foo/Cargo.toml`

Caused by:
  No such file or directory (os error 2)

I am using cargo-outdated 0.6.1.