Coder Social home page Coder Social logo

cargo-outdated's Introduction

cargo-outdated

Join the chat at https://gitter.im/kbknapp/cargo-outdated crates.io Linux: Build Status

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

About

cargo-outdated is for displaying when dependencies have newer versions available.

How it works

The functionality of cargo-outdated largely depends on the cargo builtin command cargo update.

To retrieve the list of available SemVer compatible dependencies, cargo-outdated firstly creates a temporary workspace, then executes cargo update against it, finally compares the temporary dependency tree with the original one.

Similarly, to check the latest dependencies, cargo-outdated replaces the SemVer requirements of direct dependencies with wildcards then goes through the same process.

Demo

Once installed (see below) running cargo outdated in a project directory looks like the following:

$ cargo outdated
Name             Project  Compat  Latest   Kind         Platform
----             -------  ------  ------   ----         --------
clap             2.20.0   2.20.5  2.26.0   Normal       ---
clap->bitflags   0.7.0    ---     0.9.1    Normal       ---
clap->libc       0.2.18   0.2.29  Removed  Normal       ---
clap->term_size  0.2.1    0.2.3   0.3.0    Normal       ---
clap->vec_map    0.6.0    ---     0.8.0    Normal       ---
num_cpus         1.6.0    ---     1.6.2    Development  ---
num_cpus->libc   0.2.18   0.2.29  0.2.29   Normal       ---
pkg-config       0.3.8    0.3.9   0.3.9    Build        ---
term             0.4.5    ---     0.4.6    Normal       ---
term_size->libc  0.2.18   0.2.29  0.2.29   Normal       cfg(not(target_os = "windows"))

Installing

Packaging status

The latest version of cargo-outdated can be installed or updated with cargo install:

cargo install --locked cargo-outdated

or

cargo install --locked --git https://github.com/kbknapp/cargo-outdated

Compiling

Follow these instructions to compile cargo-outdated, then skip down to Installation.

  1. Ensure you have current version of cargo and Rust installed
  2. Clone the project $ git clone https://github.com/kbknapp/cargo-outdated && cd cargo-outdated
  3. Build the project $ cargo build --release
  4. Once complete, the binary will be located at target/release/cargo-outdated

Installation and Usage

All you need to do is place cargo-outdated somewhere in your $PATH. Then run cargo outdated anywhere in your project directory. For full details see below.

Linux / OS X

You have two options, place cargo-outdated into a directory that is already located in your $PATH variable (To see which directories those are, open a terminal and type echo "${PATH//:/\n}", the quotation marks are important), or you can add a custom directory to your $PATH

Option 1 If you have write permission to a directory listed in your $PATH or you have root permission (or via sudo), simply copy the cargo-outdated to that directory # sudo cp cargo-outdated /usr/local/bin

Option 2 If you do not have root, sudo, or write permission to any directory already in $PATH you can create a directory inside your home directory, and add that. Many people use $HOME/.bin to keep it hidden (and not clutter your home directory), or $HOME/bin if you want it to be always visible. Here is an example to make the directory, add it to $PATH, and copy cargo-outdated there.

Simply change bin to whatever you'd like to name the directory, and .bashrc to whatever your shell startup file is (usually .bashrc, .bash_profile, or .zshrc)

mkdir ~/bin
echo "export PATH=$PATH:$HOME/bin" >> ~/.bashrc
cp cargo-outdated ~/bin
source ~/.bashrc

MacOS

This library depends on OpenSSL. On MacOS a newer version of OpenSSL than is installed by default is needed. This can be installed with Homebrew via brew install openssl or openssl can be vendored in with --features vendored-openssl. Learn more about building OpenSSL here,

Windows

On Windows 7/8 you can add directory to the PATH variable by opening a command line as an administrator and running

setx path "%path%;C:\path\to\cargo-outdated\binary"

Otherwise, ensure you have the cargo-outdated binary in the directory which you operating in the command line from, because Windows automatically adds your current directory to PATH (i.e. if you open a command line to C:\my_project\ to use cargo-outdated ensure cargo-outdated.exe is inside that directory as well).

Options

There are a few options for using cargo-outdated which should be somewhat self explanatory.

Displays information about project dependency versions

USAGE:
    cargo outdated [options]

Options:
    -a, --aggressive            Ignores channels for latest updates
    -h, --help                  Prints help information
        --format FORMAT         Output formatting [default: list]
                                [values: list, json]
    -i, --ignore DEPENDENCIES   Comma separated list of dependencies to not print in the output
    -x, --exclude DEPENDENCIES  Comma separated list of dependencies to exclude from building
    -q, --quiet                 Suppresses warnings
    -R, --root-deps-only        Only check root dependencies (Equivalent to --depth=1)
    -V, --version               Prints version information
    -v, --verbose ...           Use verbose output
    -w, --workspace             Checks updates for all workspace members rather than
                                only the root package
        --color COLOR           Coloring: auto, always, never [default: auto]
                                [values: auto, always, never]
    -d, --depth NUM             How deep in the dependency chain to search
                                (Defaults to all dependencies when omitted)
        --exit-code NUM         The exit code to return on new versions found [default: 0]
        --features FEATURES     Space-separated list of features
    -m, --manifest-path FILE    Path to the Cargo.toml file to use
                                (Defaults to Cargo.toml in project root)
    -p, --packages PKGS         Packages to inspect for updates
    -r, --root ROOT             Package to treat as the root package

Minimum Supported Rust Version (MSRV)

The MSRV of this crate is what is required to run cargo outdated, you may be able to compile cargo outdated itself on an earlier version of Rust. However, because cargo outdated uses cargo internally, it requires a specific minimum version to run successfully.

The current MSRV can be found in the Cargo.toml under the package.rust-version field.

License

cargo-outdated is released under the terms of either the MIT or Apache 2.0 license. See the LICENSE-MIT or LICENSE-APACHE file for the details.

cargo-outdated's People

Contributors

aerialx avatar anp avatar bors[bot] avatar chpio avatar cosmichorrordev avatar cuviper avatar deg4uss3r avatar dependabot[bot] avatar dimbleby avatar dylan-dpc avatar frederick888 avatar homu avatar huitseeker avatar jiangbinzhao avatar joelgallant avatar kbknapp avatar kjeremy avatar kornelski avatar kpcyrd avatar kraai avatar leoschwarz avatar mattico avatar mbrubeck avatar mrmaxmeier avatar nhynes avatar rmja avatar sinkuu avatar tesuji avatar vinatorul avatar waywardmonkeys avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cargo-outdated's Issues

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.

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.

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

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.

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

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.

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.

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)

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

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.

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.

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.

"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

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.

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

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.

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.

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

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 😸

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: *

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

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.

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?"

Remove unwraps

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

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.

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

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.

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.