Yanked crate shows in search list but is not installable

[colindean]

I learned about rustfmt today and learned that it has cargo integration to enable cargo fmt. I searched cargo from the command line and got this output:

± (master *%) $ cargo search rustfmt
    Updating registry `https://github.com/rust-lang/crates.io-index`
rustfmt = "0.9.0"             # Tool to find and fix Rust formatting issues
rustfmt-nightly = "0.2.13"    # Tool to find and fix Rust formatting issues
rfmt = "0.1.0"                # Another Rust source code formatter.
scout = "1.1.0"               # Small fuzzy finder for the command line
cargo-make = "0.7.3"          # Rust task runner and build tool.
bcc-sys = "0.3.1"             # Rust binding to BPF Compiler Collection (BCC)
cargo-fmt = "0.1.0"           # Allows `rustfmt` to be called through `cargo`
imgui = "0.0.16"              # High-level Rust bindings to dear imgui
harbor = "0.1.0"              # Project manager for CoreOS fleets.
aries = "0.1.0"               # a web framwork for rust-lang.
... and 29 crates more (use --limit N to see more)

Ah ha! cargo-fmt is what I want, right? RIGHT?

± (master *%) $ cargo install cargo-fmt
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: could not find `cargo-fmt` in `registry https://github.com/rust-lang/crates.io-index`

That's odd, it just showed up in the search!

I resort to the browser: https://crates.io/crates/cargo-fmt

Yanked. I think what I want is rustfmt. I installed it, and sure enough:

  Installing /Users/colin/.cargo/bin/cargo-fmt
  Installing /Users/colin/.cargo/bin/rustfmt

I think my confusion could be avoided by:

1. Convey in cargo search results that a package has been yanked. Maybe by highlighting the name in an ANSI color and outputting a colored message at the bottom that says something like "Packages in yellow have been yanked and are not directly installable. See https://somewhere.else for more information."
2. Have the crate page for cargo-fmt have some kind of text explaining why it was yanked and perhaps suggesting a next step (e.g. "Package X has superseded this package" or "This package was erroneously published" or something like that).

Start requiring a reason for all yanks #2608 is probably a necessity for the second one.

Mismatch against yanked version doesn't inform user about yank #4260 seems related.

I filed an issue with crates.io about its part in this: rust-lang/crates.io#1153

[Frederick888]

cargo search uses a SourceId which is generated here. It should be the default RegistrySource ("registry+https://github.com/rust-lang/crates.io-index") unless you override it in cargo configuration.

So based on the implementation of SourceId, SourceId::precise() is Some("locked".to_owned()) for RegistrySources. However according to the implementation of RegistryIndex::query(), this effectively disables yanked package filtering by default:

let summaries = summaries.iter().filter(|&&(_, yanked)| {
    dep.source_id().precise().is_some() || !yanked
}).map(|s| s.0.clone());

I am not quite sure why SourceIdInner::precise is not left None here. Referring to the comments in RegistryIndex::query():

Handle cargo update --precise here. If specified, our own source will have a precise version listed of the form <pkg>=<req> where <pkg> is the name of a crate on this source and <req> is the version requested (agument to --precise).

...so I reckon it should be something used to handle --precise? Then why do we make it locked by default? What does locked mean? (And why isn't it typed but using a String? Sorry for so many questions.)

The following code can quickly reproduce the problem. quickcheck 0.4.2 is yanked but in the result list.

extern crate cargo;

use cargo::Config;
use cargo::core::Dependency;
use cargo::core::source::SourceId;
use cargo::core::registry::{PackageRegistry, Registry};

fn main() {
    let config = Config::default().unwrap();
    let source_id =
        // to fix it, use SourceId::with_precise()
        SourceId::from_url("registry+https://github.com/rust-lang/crates.io-index").unwrap();
    println!("{:?}", source_id.precise());
    let mut registry = PackageRegistry::new(&config).unwrap();

    let query = Dependency::parse_no_deprecated("quickcheck", None, &source_id).unwrap();
    let result = registry.query_vec(&query).unwrap();
    for summary in result {
        println!("{}", summary.version());
    }
}

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[colindean]

This is still relevant but I think there is some plumbing that has to be done in other components before this work can be done.

[epage]

Since we already have #4260 and #2608,. that just leaves cargo search not signifying yanked versions differently.

I'm leaning towards proposing to the cargo team that we close this. Currently, we only show what the registry search returned and don't do any other processing. Once we have #948, that seems like the right way to then show more info. Also, a package that has all versions yanked seems like more of an anomaly and the cost/benefit ratio for polishing that corner doesn't seem to be there.

[weihanglo]

Second. Thanks for the triage.