So far crates-io has been lucky that it didn't have many spammy and intentionally deceptive crates, so even though plenty of signals could have been gamed, they weren't.
The new crates are unfortunately much more superficially uniform, and tick more boxes by default without even partial correlation with crate quality, protect maturity or author's experience.
Maybe some additional bits of signal can be extracted from the associated repo's git history?
Reading along this thread, isn’t it an idea to take inspiration from the music industry or steam and have a set of “curators” who rank crates? I.e., (in principle) anyone might create a ranking of a subset of crates they recommend in general, for a use-case, etc. The job of creating a reliable lib.rs then becomes choosing reliable curators instead, which may be much more manageable.
It would be somewhere in between how lib.rs works now and @ZiCog’s suggestion. Still manually curated, but the work delegated to the community. In fact, a good set of initial curators might be people from big projects, or even just bots scraping their Cargo files; but for new crates or niche communities, users might emerge that prove themselves to create good rankings and establish themselves as a reliable curator.
I don’t often chip in on this site but I like the idea of anyone being able to do their part in the reliable ranking of crates, it feels like a very open-source community idea. (And yes, I know Steam curators never grew big. But maybe this is the good medium 
)
(EDIT: Better wording)
i have a couple of suggestions:
the document would be based on an agreed template the community deems honest and reflect the opnion of its members.
the basic essence of such document is a claim of ownership in the code, and a promise to stand by its quality.
the document would be PGP signed by the author(s) of the software.
it would be renewed periodically (e.g. yearly), w/ every release, or a combination of the two. dates of first and last signatures would be listed, and tracked.
if a crate is "flagged" + "reviewed", the identity of the reviewer, the result of the review and its date would be attached to that Statement.
cheers;
rsn
Can you add a tab for me - crates with no, or < 3 dependencies? Thank you.
As a frequent flyer of lib.rs, this cry of alarm really resonated with me, leaving the question of quality signals on my mind. Inundated with a flood of a new kind of content, what new signals can we use?
What is your tolerance for static analyzers? It's one thing to flag crates that forbid unsafe. Say I wanted to scan crates for unsafe blocks so that I could label the wider set of libraries and programs that use only safe Rust, whether they specified forbid unsafe or not. Is the time and compute worth it?
What if I wanted to scan for unwrap and expect and rank libraries by panicking api? Is the juice worth the squeeze?
I would not recommend this strategy for a corpus as large as crates.io. But I use many static analysis tools like this on code I have to review, whether it is coming from a person or generated, as quality signals and foils to direct my attention.
A signal I've been using is the personal history of the crate author.
The other signals I look into is: how do they answer to issues? Do we have the best-practice quick ack + own-pace investigation, or just no response at all? What are the oldest open issues and why are they still open?
Plus general, absolutely biased, and probably not that useful, but difficult to avoid, because we are humans: "Does the maintainers seem like nice people?"
AI is very good at maintaining code. It can easily update dependencies, add and update lots of tests and documentation, fix bugs, add features.
In the last 2 months, AI changed a lot. I believe they can write maintainable and good Rust code in the near future. So, maybe AI is not the problem.
And AI may be used to judge a crate good or not, it can even be the solution.
When I meet Rust years ago, I also published some junk crates onto cratesio. And last week, I used AI to make an update of one of my crate. The new version looks good, and I rapidly published it, but eventually yanked it after carefully review. Both AI and I published junk code.
As to my suggestion, let me tell my story. I published a very bad crate at very beginning learning code. It's so bad that I cannot stand to having it in my dashboard. And I registered another github account for cratesio, and transfer the bad crate to it.
So, my suggestion is provide some official or unofficial accounts as 'ashbin' to own the bad crate. When AI users or beginners, not knowing the duty of publishing a crate, want to delete a crate, they can just transfer the crate to that account.
I believe people working with Rust and especailly who want to share their results (even AI's actually) will find the bad effect early or later, and they need an entry to put their bad crate into ashbin.
Curators could be an idea, indeed, but it's a responsibility, and they'd have to be relatively well aligned on the requirements. And 25k new crates per month means there needs to be a lot of them. I suppose a few weeks/months are necessary before any first evaluation of a given crate, if we want a significant result (since we don't want to rely on the semantic version, sadly). And perhaps a preliminary filtering of the obviously immature / already abandoned crates at this point would help reduce that number?
I'd never publish a crate if I didn't have the intention of sharing something useful. It's not a learning tool, it's a tool to share code, and it impacts everybody.
You can simply delete the crate; there's no need to transfer it. Select the crate, select the Settings tab, and the delete button is at the bottom (EDIT: See the conditions 3 posts below, though I'm pretty sure what you describe meets them).
Don't forget that 1) names are still unique, and 2) it makes it more difficult for users to select crates, not to mention the overhead on the storage and on the CPU for processes that have to go through all the crates for different purposes. Creating a 2nd GitHub account adds more overload on another platform, too.
If you want to learn how to publish a crate before you actually have something to share, you can do a dry run with the -n or --dry-run flag.
Perhaps adding badges and encouraging maintainers to use them in some circumstances would help.
I have one crate that's mature and doesn't require any more updates. After a while, I got a hint that a maintenance badge could clarify its status (I don't remember if it was on lib.rs or crates.io, but I think it was the former). I thought it was a great idea; I didn't even know it existed. I added this to clarify the status:
[badges.maintenance]
status = "passively-maintained"
There's a risk maintainers forget to update it, so it's not perfect.
From Publishing a Crate to Crates.io - The Rust Programming Language
Although you can’t remove previous versions of a crate, you can prevent any future projects from adding them as a new dependency
It was always my feeling that we can not delete crates after publishing them -- I think I read the same from the book of Jim Blandy "Programming Rust".
It's detailed here, and there are conditions:
Crate owners can delete their crates under certain conditions: the crate has been published for less than 72 hours, or the crate only has a single owner, the crate has been downloaded less than 1000 times for each month it has been published, and the crate is not depended upon by any other crate on crates.io. If these conditions are not met, the crate will not be deleted. In exceptional cases crate owners may contact the crates.io team to request deletion of a crate that does not meet these conditions.
Also:
The crates.io team may delete crates from the registry that do not comply with the policies on this document. In larger cases of squatting attacks this may happen without prior notification to the author, but in most cases the team will first give the author the chance to justify the purpose of the crate.
Not really. Take the page from Steam: even getting accepted to the “early access” is not trivial and requires to jump a lot of hoops. And that's fine.
The problem is that the majority of these crates are from people who don't plan to support them, are not interested to work with others and are not planning to work with the community.
They uploaded their crates to crates.io because it was easy, not because they had any future plans. So let's just make them dark on lib.rs (or maybe add a separate tab where they would live), this wouldn't affect that 90% of them (if not 99% of them).
Change the logo and tell that lib.rs includes the list of reviewed crates, make the job of finding trusted reviewer a candidate problem, bring human back in the loop.
It doesn't matter whether AI produces slop or something usable: AI is not human, if someone uses AI and doesn't want to work with humans then let's simply ignore them, if someone wants to work with human then treat their code as something you would look on after talking to said human…
If time to find reviewer would be measured in weeks or months then most AI crates would go dark… and there's nothing wrong with that: if their own creators couldn't be convinced to care why anyone else should care?
Welcome to real world. The majority of crates come from people who treat cargo.io as a dumping ground. You may not like that but that's how it works.
There is an another problem, at least for me. For example, I use tinyzip, however, I need to get timestamp from the header. Currently, the crate doesn't support the feature directly, so I issued a simple patch and start using it. After sometime I need again to extend it by adding support of Unix file attributes as permissions. Again, it's a simple patch. Other people may need a similar changes, however, my changes are hidden for them. So, if I created libs.io, I would add a possibility to attach extension patches to any crate. The crate maintainer may decide if (s)he wants the patches and apply them to the next version of the crate. However, other people will always have an access to possible extensions and use them regardless the maintainer wish. It's better than duplicating work even if it's done by AI.
sounds like you should submit a PR with your changes to tinyzip and they'll hopefully include them in the next release
Thanks got we don't have it. We already have enough trouble trying to understand the mess with existing crates. The last thing we need is to add combinatorial explosion for crates that are extended in random directions by random people.
It's easy to create a tiny oatch, but who would coordinate all the mess created from patches that upstream doesn't accept your patches (if upstream is responsive and accepts patches then all that complexity is not needed by definition).
I think any opinion has a good sense. Probably, some will find it's bad and coming out of the control. However, I believe that a real gems are hidden in the mess.
Absolutely! But no one will ever find them there. Except maybe someone who already knows they are there, because they would receive information about these gems via some kind of side-channel, but these would also know and have access to these gems via said side-channel.
If there are no good way to pull gems from the mess then removing the mess with these existant but non-findable gems is preferable than keeping mess around.
We went from the world where information was valuable and hard to come with (till the end of XX century) to the world where we need to learn to ignore the majority of it (because so little of information is original and so much of it is fabricated).
Different world, different rules.
Codeberg attempt is interesting, but probably wrong… we would see others.
Well, I could use being hosted on codeberg as a positive ranking signal 