Hacker News Reader

Comment by fawadasaurus | Hacker News Reader

I did some analysis on crates.io to find the top name squatters. Then I did some calculations and found that the top name squatter created their crates at a rate of about one ever 30 seconds for a period of a week straight.

I send the analysis to the crates.io team and pointed that they have a no-automation policy.

They told me that it was not sufficient proof that someone was squatting those names. That's my problem with crates.io is that they have a clear policy and they don't enforce it so all the short/easy to remember names for crates are already taken and there is nothing you can do to get it.

View on HN

There's a HUGE gap between

> Using an automated tool to claim ownership of a large number of package names is not permitted.

And

- Hey, I found that someone created crates at a rate of about one every 30 seconds for a period of a week straight.

- That's not sufficient proof of squatting.

Whoever answered that, was either supporting the squatter or explicitly in favor of the practice. I cannot conceive that someone would get that evidence in their hands, and in their right mind think that the claim is bogus. Hell, I'd even be willing to suppress the squatter with evidence of one new crate created every 30 seconds for one hour!

The only reasonable conclusion to make is that they didn't really care. But then don't save face and claim that you do. That's hypocrisy.

In July 2023 the crates.io team started asking for feedback around changing their policy around name squatting - https://rust-lang.zulipchat.com/#narrow/stream/318791-t-crat...

There's a secret effort in the Rust community to supplant Crates.io and create an entirely new package ecosystem with proper namespacing, security, and much better community.

Not naming names, but I know several people working to put Crates.io out to pasture.

There's a level of playing nice with them for the time being (eg. build reproducibility), but it's only KTLO.

Crates.io needs to die for Rust to thrive. They're a bungled, mismanaged liability. New code, new leadership.

Why does something like that need to be secret...? Isn't it in the community's best interest?

Drama avoidance and avoiding bikeshedding seem obvious. Much easier to present a working system than a design that will get nitpicked into irrelevancy.

Yeah, that makes sense.

That quite funny. Just like when some people formed a violent militant group to take down a violent tyranical dictatorship. Of course they would promise that they would absolutely de-arm right after the dictatorship has been overthrown, and immediately establish a peaceful democratic government with fair election. They absolutely would, would they? They would never turn into what they were formed to replace, would they?

If one tyranny has namespaces and the other doesn't, I'll prefer the former.

    pub use std::sic::semper;

     const step_on_snek = false;

Crates.io doesn't need to die necessarily. It needs some competition as a wake-up call.

Once a better alternative is out there, crates.io will either wither and die or improve. If it matches its competition in terms of quality and reliability, everyone is better off. If not, the alternative solution will take over.

I'm eager for this crates.io alternative to land, assuming they don't break too many projects in their improvements.

How secret is it now that you've posted on HN about it?

Wait I thought only I could read the secret

yes, HN hides secrets automatically

******* is my password, but you can't see it. Type your password back, and I won't be able to see it. Try it!

I'm not sure it's working the way you described:

hunter2

It’s working. I really can’t see it. All I see is ****

Maybe you are getting tricked to give out your password...

https://knowyourmeme.com/memes/hunter2

tr!pt0ph@n3

It's an open secret.

Hilarious.

I find this interersting as most namespacing solutions would need the cargo team involved and I've heard nothing about this.

This was my first thought too. And there are a lot of questions that will get asked, like, will all crate library names start being prefixed as well? So you end up with

use::bar; // changing to

use::foo::bar;

I assume the library names that can be overridden in cargo would still be accepted, and then it all gets a little messy. The transition would be very messy.

My preferred syntax route is a new separator in package names and the lib name gets populated by everything after it.

Still doesn't solve all of the policy problems with namespacing.

crates.io is fine.

> they have a no-automation policy

What's that? I have scripts that automate publishing of new release of my crates. And I think many projects have.

Of course that's permitted.

What they stated was only regarding claiming new ownership over crate names:

> Using an automated tool to claim ownership of a large number of package names is not permitted.

Write some automated analysis that looks up popular packages on npm, pub.dev, rubygems, nuget. "Rustify" the package names. Add to it frequently used words, maybe popular names, etc. Then, write a script that creates an empty package, registers a name on crates.io every thirty seconds, and then you have about 20k package names after a week that nobody can use.

Reply on news.ycombinator.com