Only crates without reverse dependencies can be deleted, except this one has none

[clarfonthey]

Current Behavior

Right now, I'm trying to delete value, an extremely old crate of mine which has seen minimal use and doesn't seem very useful. It seems unreasonable to effectively squat such a common word, but I can't delete it because it claims that it has reverse dependencies, even though it has none.

I think it may have had reverse-dependencies with another crate that I also deleted, but the database is inconsistent and thinks otherwise.

Expected Behavior

I should be able to delete it.

Steps To Reproduce

No response

Environment

No response

Anything else?

No response

[Turbo87]

the "Dependents" tab only shows reverse dependencies for the default versions of other crates (for performance reasons). if an older release of a crate has your value crate as a dependency then that reverse dependency won't be shown, but unfortunately still prevents you from deleting your crate, since the older version of that other crate would be broken without your crate existing.

[clarfonthey]

That makes sense, but it's very unfortunate that I can't actually check what those crates are, since it is blocking deletion.

[Turbo87]

yeah, unfortunately it's currently only possible to figure out via the database dump 🙈

if you want to help out, I guess a good first step for now would be to improve the error message that prevents the deletion to explain why the "Dependents" tab potentially shows something different.

[clarfonthey]

So, not to focus too much on this point, but I do think that the issue in this particular case is that the dependents were packages that I had published and subsequently deleted.

Assuming there isn't anything super wrong with this methodology, I just searched the git index for reverse dependents exhaustively and came up empty. Specifically, with this script named ./hasdep:

#!/bin/bash
check="$1"
for crate in "${@:2}"; do
    if ! jq -se "[.[].deps[] | select(.package == \"$check\")] | length == 0" "$crate" >/dev/null; then
        echo "$crate"
        jq -s "[.[].deps[] | select(.package == \"$check\")] | unique" "$crate"
    fi
done

Running fd -tf -x ./hasdep value shows no results. Meanwhile, if I replace value with a popular crate like serde, I get flooded with results immediately.

So, I do think it's what I suspect, where deleted crates are still being counted here.

EDIT: Gonna try my hand at checking the database dump, since I hadn't realised that database dumps were actually publicly offered.

[clarfonthey]

Okay, found it. The singular reason why this crate can't be unpublished is because there was a singular crate version, blaze-common@0.1.0 which was published a year ago that depended on version 0.1.0 of the value crate, and was yanked. Considering how the crate now depends on hash-value, it feels like the original dependency on this version was a mistake.

Edge cases like this are why I initially showed some apprehension on the initial crate deletions RFC, thinking that the requirements were too strict. I'm not sure what the exact modification to the rules should be here, but considering how the singular version is well below the download requirements (~1000 downloads for a singular year) I think that we should be allowed to remove yanked versions to satisfy requirements for crate deletion as long as they also match the download/age requirements.

Part of the reason why I want to delete the crate is because of mistakes like this, and because again, it's such a canonical-sounding name for a not-very-useful crate that was published years ago.

Also, as part of potentially fixing this issue, I think that the dependencies/dependents page should be able to easily show non-latest crate versions given the current tables the database has. It doesn't feel that hard to also use some fancy aggregate SQL to show the latest version that the dependency was present for, and then sort non-latest versions at the bottom of the list for pagination purposes.

---

Also additional note: upon downloading blaze-common@0.1.0 and the immediately following (also yanked) version 0.2.0, it becomes immediately clear that this was a typo that wasn't detected because older versions of cargo didn't test code before publishing, because it tries importing paths that are present in hash-value and not present in value. So, we can pretty safely say that this was unambiguously a mistake here, and that this version would never have compiled if built properly.

[Turbo87]

I think that we should be allowed to remove yanked versions to satisfy requirements for crate deletion as long as they also match the download/age requirements.

you might want to read through https://rust-lang.zulipchat.com/#narrow/channel/318791-t-crates-io/topic/Old.20index.20entries.20being.20modified/with/572015488 to understand what makes this hard in the current implementation.

I think that the dependencies/dependents page should be able to easily show non-latest crate versions given the current tables the database has

even the current somewhat optimized query is already performance issue and can take literally seconds to complete for crates that are used by many other crates. you are welcome to import our database dump to a local postgres instance and see if you can find a way to make this work in a scaleable way 😅

[clarfonthey]

If you happen to have any examples of crates where the query is particularly slow, I do have a few ideas on how to speed it up, and examples are always nice.

If you don't have any, I can still try, but I figured there's a chance you have some slow query logs with examples.

[Turbo87]

my goto example is usually serde. but due to database cache invalidations in production the query usually runs significantly slower on a real life system.