I'm not sure how to call it exactly, but it would be great if cargo add supported adding "short" caret versions (which are "just" versions in Cargo, without any sigils), i.e. major.minor instead of major.minor.patch. As far as I understand semver, this should really be the default mode, as patch versions should keep backwards compatibility and are safe to upgrade to. Adding full versions by default is too restrictive, I believe.

Like @rgardner described in #25:

• removing an existing dependency works
• removing an existing dependency from a specific section works
• removing a non-existing dependency shows a nice error message
• removing an dependency from a non-existing section shows a nice error message
• remove the section when the last dependency has been removed

I've never been able to get cargo add to add multiple crates at once. I always get a 404 from crates.io:

$ cargo add iron log mount
Command failed due to unhandled error: crates.io Error: NotFound

I've ensured I have the latest version installed and have tried using commas instead of spaces as the separator, but I always get this result.

Examples:

error_def

$ cargo add error-def
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
no matching package named `error-def` found (required by `undered`)

quick-error

$ cargo add quick_error
$ cargo build
    Updating registry `https://github.com/rust-lang/crates.io-index`
no matching package named `quick_error` found (required by `undered`)

$ cargo list --tree
Your Cargo.toml is missing.

Running the same command without --tree works fine.

• Tests for sections
• Tests for useful errors

I've been working on a commercial project in Rust and I've just realized that with just 3 dependencies in Cargo.toml I have 61 transitive dependencies.
It would be nice if I could easily list the license for all of them, to be able to quickly identify potentially problematic crates (GPL comes to mind, but there are probably others that cannot simply be included in arbitrary commercial software).

Use optional flag to set, well, the optional flag of a dependency.

--optional      Add as an optional dependency (for use in features). This does not work
                for `dev-dependencies` or `build-dependencies`.

Why is this? Several of my projects have a build dependency that is optional, and I always have to move things around manually since cargo add has this limitation.

• List all features used in the Cargo.toml
• Recursively list features of sub-dependencies and indicate whether they are active

Suggested by @gkoz in #20.

I'm not saying ‣ is bad, but exa's tree looks cooler.

Obviously I need to install ssl and crypto libraries but perhaps a check and a better error message would be in order for future users.

   Compiling cargo-edit v0.1.6
error: linking with `cc` failed: exit code: 1
  |
  = note:

...

  = note: /usr/bin/ld: cannot find -lssl
          /usr/bin/ld: cannot find -lcrypto
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: failed to compile `cargo-edit v0.1.6`, intermediate artifacts can be found at `/tmp/cargo-install.s6heJAMi41R8`

Caused by:
  Could not compile `cargo-edit`.

cargo add https://github.com/Manishearth/rust-clippy could, in theory, fetch the Cargo.toml file (https://raw.githubusercontent.com/Manishearth/rust-clippy/master/Cargo.toml) to infer information about the dependency.

It might be a good idea to enable doing certain fixes (as suggested in cargo build error messages) either automatically or with a new switch.

For example, if I had a new rustc target named atom-unknown-linux-gnu, I might need to add it to Cargo toml in:

.cargo/registry/src/github.com-121aea75f9ef2ce2/glutin-0.3.5

or if using a nightly and getting an error suggestion #![feature(core_intrinsics)] is required in some crate, it could speed up adding that line to lib.rs located in:

.cargo/registry/src/github.com-121aea75f9ef2ce2/gfx-0.7.0/src

Preferably features such as these could land in cargo itself at some point in the future.

As suggested by gkonz on reddit.

(This should be pretty easy and basically only list files in a directory.)

Similar to this, only for cargo:
https://github.com/tjunnone/npm-check-updates

Maybe this feature already exists but i couldn't find it, and nobody at the last meet knew about it.

Shouldn't we add a deprecation warning to cargo list until it is removed in 0.2?

As mentioned in #42, #47, and #48, cargo list needs to be refactored.

I suggest to first change it to only allow cargo list [--dev|--build], which lists (dev-/build-)dependencies. This includes:

• List dependencies by section
• Correctly show dependencies with version, path, repository (cf. #48)
• Indicate whether a dependency is marked as optional

Some time ago, I already created a few issues that describe further options. For the record, those are:

• cargo list (bins | tests | examples) (#20)
• cargo list features [--recursive] [--manifest-path] (#21)

As reported on irc by seekr, cargo install --git "https://github.com/killercup/cargo-edit.git" --branch "feature/hyper-hyper" does not work, most likely there's a problem with Cargo.toml files in the tests directories (thanks, sfackler). An easy fix would be to rename them.

• Useful error messages
• Manifest lookup
• TOML Structure (cf. #15)

• Don't mess up Cargo.toml structure too much, e.g. keep the ordering
• Don't remove comments.
• Use inline tables whenever possible, e.g. clippy = {version = "0.0.19", optional = true}

This should work:

$ cargo add regex@^0.1 nom
Command failed due to unhandled error: crates.io Error: NotFound

Currently cargo-add removes comments from the Cargo.toml file

[/tmp/a (master#%)]% cat Cargo.toml
[package]
authors = ["author"]
name = "a"
version = "0.1.0"

# Comment
[/tmp/a (master#%)]% cargo add rustc-serialize                            
[/tmp/a (master#%)]% cat Cargo.toml           
[package]
authors = ["author"]
name = "a"
version = "0.1.0"

[dependencies]
rustc-serialize = "0.3.16"

It would be nice if it can leave them untouched. Especially in development it might happen that some comments are left in.

Move to current functionality into separate binaries:

• #1: cargo list <section> [--tree] [--help] [--manifest-path]
• #8: cargo add <name> [--version|--git|--path] [--dev|--build]
• #6, #10: Update Readme, docs

Adding a dependendency shows up with cargo list:

$ cargo add lazy_static
$ cargo list
lazy_static 0.2.2
libc        0.2.17

However, cargo list --tree does not:

$ cargo list --tree
└── libc (0.2.17)

The dependency does not show up with --tree until I've done a build and the new crate is downloaded. Ideally cargo list would be consistent with cargo list --tree.

Given this Cargo.toml:

[package]
authors = ["Yohai Berreby (filsmick) <[email protected]>"]
name = "cargo-edit-bug"
version = "0.1.0"

[dependencies]
quick-error = "0.1.3"
time = "0.1.32"

cargo rm quick-error produces the following invalid .toml:

[package]
authors = ["Yohai Berreby (filsmick) <[email protected]>"]
name = "cargo-edit-bug"
version = "0.1.0"

[dependencies]
time = "0.1.32"
.1.3"
time = "0.1.32"

This is not related to the '-' in the crate name:

[dependencies]
foo = "0.1.3"
bar = "0.1.32"

becomes

[dependencies]
bar = "0.1.32"
ar = "0.1.32"

after cargo rm foo.

Last but not least: cargo rm bar on the previous example doesn't change Cargo.toml at all.

It seems related to the patch version: I couldn't reproduce the problem when a major.minor version was specified.

See facebook/hhvm#6288 and sfackler/rust-openssl#305. TL;DR: SSLv3 support was removed from recent openssl versions. rust-openssl and curl-rust were updated. The current version of cargo-edit on crates.io apparently still depends on older versions of these crates, because it fails to build with cargo install on my machine without SSLv3 support.

Quite often during development when I want to test out how changes in a deeper dependency affect a crate, I add that dependency to the paths attribute of .cargo/config. (and AFAIK that is the only way to achieve that specific override behaviour.

I would propose to use a additional --override flag which would then use the following argument as the local path:

cargo add --override /my/local/crate

I would also understand it if you would prefer a more explicit usage, requiring the --path attribute like so:

cargo add --override --path=/my/local/crate

I don't know what other functionality is provided trough the .cargo/config file (and how to integrate them), since that above use case was my primary motivation.

I would love to get some feedback on the command syntax and/or if you would like to have support for editing .cargo/config file at all in cargo-edit.

This is probably out of this crate's control (as I imagine toml just skips over commented lines, as it probably should), but I was disappointed to find out that cargo add'ing a dependency rewrote my entire Cargo.toml, removing a commented-out feature that I wanted to save for later.

Feel free to close this as wontfix, but I think it would be really neat if the Cargo.toml could be rewritten while preserving comments, as there could be significant amounts of documentation in comments for the reasoning on various dependencies and features.

Right now, if not explicitely specified, cargo-add will add the latest release version of a crate. Sometimes the latest one is an alpha release and instead the last stable one should be used.

Example: *ring* v0.6.0-alpha vs v0.5.3

cargo list --tree is very useful in finding where multiple package versions are pulled into the dependency graph.

With packages sourced not from crates.io, but from local paths or remote git repos, the version number can be misleading, because the repo might have the same version as the crates.io package, but they are still different packages. Could cargo list show the package source if it's not crates.io?

The first implementation of cargo install landed last night! 🎉

So, let's get cargo-edit ready for a 0.1 release and publish it to crates.io. Ideally, I want to cargo install cargo-edit tomorrow!

A few things to note:

• This will be a 0.1 release not promising any kind of stability of anything, least of all the CLI arguments!
• For testing, cargo install --git https://github.com/killercup/cargo-edit.git should work
• I just notices cargo install --vers is equivalent to cargo add --ver. Maybe we want to change to also use --vers?

I just ran cargo add generic_matrix. It worked, even though the crate on crates.io is actually named generic-matrix. It added the version bound based on the correct package, but of course when trying to build afterwards, cargo couldn't find generic_matrix.

Like @gankro and @filsmick described on Reddit, cargo add could learn to add dependencies with versions that are already used by another dependency.

Let's say I have my-http-thingy = "0.4.2" already in my Cargo.toml. Now, we run cargo add my-url-parser. Instead of fetching the latest version (e.g., 6.6.6), we should first suggest to use 1.3.37 which my-http-thingy already depends on (and which is incompatible to the latest version).

I'm not sure if we should do this in every case. If part of my dependency tree looks like a (0.2.1) → b (0.4.2) → c (0.6.0) → d (1.2.0) and I want to cargo add d, is the version c depends on still relevant? How should we tell this to a user?

Should we give the user a choice or should we only do this when a special argument is given (e.g., --infer-versions, or --keep-dependencies-flat)? (Personally, I thing interactivity is okay for cargo add, even though it might make the code more complex and we should offer an op-out).

$ RUST_BACKTRACE=1 cargo add libc
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: failed init', ../src/libcore/result.rs:799
stack backtrace:
   1:     0x2b52832599bf - std::sys::backtrace::tracing::imp::write::h6f1d53a70916b90d
   2:     0x2b528325cf5d - std::panicking::default_hook::{{closure}}::h137e876f7d3b5850
   3:     0x2b528325beea - std::panicking::default_hook::h0ac3811ec7cee78c
   4:     0x2b528325c488 - std::panicking::rust_panic_with_hook::hc303199e04562edf
   5:     0x2b528325c322 - std::panicking::begin_panic::h6ed03353807cf54d
   6:     0x2b528325c260 - std::panicking::begin_panic_fmt::hc321cece241bb2f5
   7:     0x2b528325c1e1 - rust_begin_unwind
   8:     0x2b52832979cf - core::panicking::panic_fmt::h27224b181f9f037f
   9:     0x2b528324c114 - core::result::unwrap_failed::h27844398571de25d
  10:     0x2b528324e57c - curl::http::handle::Handle::new::hc96cb285218d129a
  11:     0x2b528315bd51 - cargo_add::fetch::get_latest_dependency::h387b0ad0c0352809
  12:     0x2b5283161fcc - cargo_add::handle_add::h5b1228548cd89fc4
  13:     0x2b52831636c7 - cargo_add::main::ha18a7ae612e2c426
  14:     0x2b5283264a26 - __rust_maybe_catch_panic
  15:     0x2b528325b761 - std::rt::lang_start::h538f8960e7644c80
  16:     0x2b528457d9f3 - __libc_start_main
  17:     0x2b5283155818 - <unknown>

This is on a machine that requires using a proxy to access URLs.

I get the same error even if I set HTTP_PROXY environment variables.

Shall cargo add, cargo rm and cargo list actually be cargo dep add, cargo dep rm and cargo dep list?

I think dependency list is not the only list that can be in Cargo project. For example, one may suggest that cargo add myothertool.rs would crate new [[bin]] section for myothertool...

Are other edits of Cargo.toml (like updating a homepage or documentation URI) also in scope of cargo-edit?

If the Cargo project contains a single library or executable, it might be nice to have a flag that automatically adds a extern crate X; statement to the main.rs or lib.rs file.

Have you thought about this?

Add a --target=<triple> flag to specify a dependency for one target architecture only.

I recently stumbled upon this problem when trying to add 'sdl2_image' using cargo-edit.
The most recent version is yanked, which means that it shouldn't be added.
(To see it, go here)

Like cargo add, but removes dependencies from the Cargo.toml.

I'm trying to diagnose why installation of cargo-edit with the MSVC toolchain is failing, and based on discussion in alexcrichton/curl-rust#92, it looks like the problem is you're depending on too old a version of curl. Could the dependency be updated?

When not specifying the version of a crate (e.g. cargo add regex), automatically make a request to crates.io to determine it (see comments below).

Wildcard dependencies like regex = "*" are evil.

Possible errors to consider and handle:

• "crate not found"
• "could not connect to crates.io"
• "could not parse crates.io response"

I am trying to install cargo-edit but it fails with cargo install

I get this error message:

failed to unpack package `cargo-edit v0.1.1`

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

I get the same error when I try installing via cargo-extras

failed to compile `cargo-extras v0.3.0`, intermediate artifacts can be found at `/home/azerupi/target-install`

Caused by:
  unable to get packages from source

Caused by:
  failed to unpack package `cargo-edit v0.1.1`

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

This is probably connected with this cargo issue: rust-lang/cargo#2326

The following is an entirely valid manifest with no dependencies:

[package]
name = "root"
version = "0.1.0"
authors = ["Vladimir Matveev <[email protected]>"]

However, cargo list shows an error when run against it:

% cargo list
Could not list your stuff.

ERROR: Couldn't read section dependencies
Couldn't read section dependencies

Adding an empty [dependencies] section fixes it, but it should be unnecessary.

Add Steve's description that Cargo assumes 1.2.3 → ^1.2.3 == (>=1.2.3 and <2.0.0) to cargo-add's help text.

Currently cargo list only displays the version-requirement specified in Cargo.toml. It would be nice to be able to list that along with the actual selected version of each package (the version displayed by cargo list --tree).

I have some code which works but I'm also testing with listing the latest version from crates.io too, might be interesting to merge the two functionalities together (optional of course, since finding the latest version requires an internet connection), along with optional coloring of the dependencies depending on if they are up to date or not. If there is enough interest I can clean it up and make a PR.

When starting a new project, I'll often know about several things I'll need/want, e.g. hyper serde serde_json for a typical web project, or for a library project quickcheck quickcheck_macros as dev-dependencies. It might nice to allow adding multiple crates.io in one go, e.g.

$ cargo add hyper serde serde_json
$ cargo add --dev quickcheck quickcheck_macros

I guess this may not allow specifying versions (although one could do something like cargo add hyper --vers 1.0 serde --vers 2.0, maybe?).

This allows us to fix #15

In #49 I tried to add AppVeyor (a CI for Windows) by copying the config used by regex. It didn't work for each target and I have no way to debug and fix this.

I'd be very happy if someone could have a look at this! 😃