search

rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.8k stars 2.42k forks source link

bdf regress because bit-set 0.3.0 disappeared in the recent few months #14643

Open tommythorn opened 1 month ago

tommythorn commented 1 month ago

Current Behavior

I depend on the bdf crate and it worked fine a new months ago (at least as recent as June 4th). Alas, it fails now due to...

error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Expected Behavior

It should work

Steps To Reproduce

I can also reproduce this with

$ cargo new brokeness;cd brokeness;cargo add bit-set@0.3.0;cargo check
    Creating binary (application) `brokeness` package
note: see more `Cargo.toml` keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
    Updating crates.io index
      Adding bit-set v0.3.0 to dependencies
             Features:
             - nightly
    Updating crates.io index
     Locking 3 packages to latest compatible versions
      Adding bit-set v0.3.0 (latest: v0.8.0)
error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Environment

This happens on all platforms

Anything else?

Aren't crates supposed to be immutable for life?

tommythorn commented 1 month ago

Yumechi-san kindly helped: "Crates were immutable but toolchains were not, so some dependency definitions become invalid when you update.

The error I see on your package says bit-set has a Cargo.toml which depends on bit-vec but has absolutely no version specifier (not even a '*'), that is probably what is broken, I would still fork bdf and update the bit-set dependency."

I guess I didn't know this could happen (which seems quite bad).

Feel free to close this if there is nothing more to add.

epage commented 1 month ago

The change in question is rust-lang/cargo#13775 which we further talked about in rust-lang/cargo#13824.

My main concern is with the error message reported in the issue. When I run this, Cargo gives some more detail than mentioned in the issue.

$ cargo check -V
cargo 1.81.0 (2dbb1af80 2024-08-20)
$ cargo add bdf
    Updating crates.io index
      Adding bdf v0.6.0 to dependencies
    Updating crates.io index
     Locking 10 packages to latest compatible versions
      Adding bit-set v0.3.0 (latest: v0.8.0)

$ cargo check
  Downloaded thiserror-impl v1.0.64
  Downloaded thiserror v1.0.64
  Downloaded syn v2.0.79
  Downloaded bit-set v0.3.0
error: failed to parse manifest at `/home/epage/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bit-set-0.3.0/Car
go.toml`

Caused by:
  dependency (bit-vec) specified without providing a local path, Git repository, version, or workspace dependency to u
se

$ cargo +nightly -V
cargo 1.83.0-nightly (eaee77dc1 2024-09-19)

$ cargo +nightly add bdf
    Updating crates.io index
      Adding bdf v0.6.0 to dependencies
    Updating crates.io index
     Locking 9 packages to latest compatible versions
      Adding bit-set v0.3.0 (available: v0.8.0)

$ cargo +nightly check
error: failed to download `bit-set v0.3.0`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `/home/epage/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bit-set-0.3.0/Cargo.to
ml`

Caused by:
  dependency (bit-vec) specified without providing a local path, Git repository, version, or workspace dependency to u
se

It says what manifest failed and why. While cargo tree -i bit-set does no work, you can browse crates.io for what depends on bit-set.

As we rework some of Cargo's error reporting, this does want me to make sure we do as much error recovery as possible and allow cargo tree to still report a tree on error.

I do find it strange that nightly added "failed to download" and "unable to get packages from source". 1.82 also has that message. After further investigation, it turns out it is not associated with the version but if the package was already downloaded. My message changed on 1.81 and doing rm -rf ~/.cargo/registry brought it back again. We have some gaps in our adding of error context (and our error context is a bit inaccurate in this case).

Turbo87 commented 1 month ago

@rustbot transfer cargo

rustbot commented 1 month ago

Error: This repository is not enabled to use triagebot. Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

tommythorn commented 1 month ago

Thanks Ed. FWIW, as a still green ruster, none of the error messages above are clear to me. Like it was not at all obvious that this happened because I upgraded my tools.

epage commented 1 month ago

Yes, identifying a problem is in a change in a tool is a harder problem to call out.

Turbo87 commented 1 month ago

let's try this again:

@rustbot transfer cargo

epage commented 1 month ago

For me, the question at this time is what, if anything, we should do for this case.

As shown in my post, the error message at least calls out that bit-set can't be parsed and why. As this is a hard error, this is unlikely to spread to new cases

Options