So I wanted to publish my package, when I saw that the name is already taken, I got curious who is using it. It was completely empty package. No code was written. It got even more interesting when I decided to check out his profile.
He has about 100 completely empty packages with useful names reserved (like bind , boost , bash , benchmark , any , fb , jquery , iterator and even fuck ). It says WIP. Contact me if you want to use this name , but no contact information provided.
And even if there is and it's just I didn't find it, it feels like some sort of a scam to me. My guess is that he will try to sell these names (again, it's not confirmed, it's just my theory).
My impression was more that some members believe Newton's 4th law of the universe states that "it is impossible to judiciously police crate names". All suggestions just get deflected to the bin.
It's a hard problem. Many of the suggestions weren't solving only the name squatting issue, instead trying to come up with some sort of security/trust model to prevent malware delivery, left-pad problems, etc. And if you only want to solve the squatting problem, then you've got to manually mediate everything anyway, so a user already has to operate under the premise that they won't get the name they want. (If I wanted to name my own crate "bitflags", then how do we resolve that? How do we determine who gets priority, or what a "legitimate" crate is?)
Answering these kinds of questions seems to have lead into a complexity spiral.
I agree, but it's hard to formalize that clarity into a policy without simply giving someone the power to remove crates and hoping the community backs them up well enough to avoid dragging things into a muddy conflict every time they exercise that power.
Having policy that forbids squatting is not equal to "simply giving someone power to remove crates". It neither has to be one person, nor absolute power. There are many possible policies and courses of action. There's already an RFC exploring policy and limits that can be applied: https://github.com/rust-lang/rfcs/pull/2614
Policing of squatting is a form of conflict resolution. It doesn't create muddy conflicts: it's meant to help settle on the least bad resolution of conflicts that have already arisen, and prevent new disputes from arising by banning bad behavior.
All I'm trying to say is that there's a lot of different ways forward and no clear winner. Not that there isn't a winner at all.
Users who have their crates removed create those conflicts. Spiteful people who feel like they are entitled to do what they will, either in squatting themselves or in reporting squatters.
I'm not advocating for or against any crates.io policy. Personally, I find cargo is flexible enough that the upper bound on the severity of this problem is quite low in practice. I'm just as happy pointing people to GitHub as I am crates.io, and it is the administrators of crates.io who have to do what is best for them to achieve their own goals. Rust already meets all of my needs regardless of this policy, because I don't require crates.io for pretty much anything. It's convenient, but that's all.
I don't quite understand what you mean by that. But deciding who's to "blame" for a name conflict is something that belongs to a squatting policy. Either side of the conflict could be at fault, which is why I'm not happy with the current "no-policy" policy that by inaction always blindly favors one side.
What I mean is that it would be very rude to pull someone's crate without talking with them, or equivalently to force them to engage in a negotiation because some third party has a problem with their crate name. Blindly favoring the first publisher may not create the ideal ecosystem, but it means that people aren't forced to engage and that they always have a clear, non-political answer to why person X owns crate Y: they got there first. Those advantages shouldn't be overlooked.
That's not what has been proposed. The current RFC proposes contacting the author before pulling the crate, and allows disputes only under specific requirements like X years without an update. I think that's a pretty good protection from unjustified disputes.
Choosing not to do anything about an issue is also "political". It is a policy that has been decided.
Well.. The Perl community has CPAN which is analogous to crates.io. They also have this PAUSE. Obviously, they have been there before and have handled similar issues on CPAN successfully in the past. Why not make use of (some of) their policies for resolving this particular problem ? For instance; their co-maintainership policy sounds like a novel approach to the problem. Here is the relevant part in which some of their policies regarding this issue are described in detail: About PAUSE
Honestly, I don't understand why namespacing has been excluded completely.
I find the arguments against namespacing quite weak. The main one seems to be "namespacing doesn't solve all the problems". But at least it solves 90% of them.
Namespacing has been adopted successfully by many other communities (PHP, Java, Go) in different forms.
Hoping a code of conduct can solve the problem in a community that grows as fast as the Rust one is just wishful thinking.
It's extremely easy to do. Very simple and straightforward. Look at it, and if it's obvious that it's bad name squatting, stop it from happening. Trying to branch out a new field of philosophical ethics about name squatting is admirable, but ultimately unnecessary. Just hit the 'transfer name' button here. Done. Easy
A few approaches to namespacing have been proposed, but there are technical difficulties around it affecting not just crates.io, but support for namespaces in the compiler interface and the language. Plus we 20000 non-namespaced crates already and they have to continue to work without creating a break in the ecosystem.
The most backwards-compatible namespacing solution so far could be to require crate names to be prefixed with username, e.g. Alex_PK-cool_crate_name, and figure out policy for current crates that don't follow it, or clash with it. Personally I'd like that if it was optional for orgs, e.g. tokio-* or winapi-*, but we'd have similar problem with people squatting good prefixes.
But in the end it solves problem of nice crate names taken by forbidding all nice crate names and making them all long, plus more vulnerable to typosquatting. (quick: is retep988/winapi legitimate or typosquat?)
Has anyone tried asking for one of those names? If the answer is, "Sure, dude.", there's no problem. If the answer is, "Sure, dude, for $100.", then we have a problem. If the answer is, "No, I'm planning to provide code for them.", we're in a gray area.
I think we can be flexible and allow someone to grab a few (<5?) related names and leave the crates empty for a couple of weeks while working on actual implementations. Grabbing 100 names and leaving the crates empty for months is a clear abuse, and I see no harm in the crates team reclaiming a name if someone else wants it.
Of course, that's easy for me to say; I'm not the one who will have to handle disputes.
