I'd like to use a crate name, which was reserved on crates.io

I'd like to create a crate contract, which was reserved by swmon, who reserved dozens of crates without using it at all, just as described in this reddit post.

What exactly I have to do, to get one of those names? I honestly don't see the point of using a different name just because some idiot thinks he's reserving such names without using it.

7 Likes

It's not against any crates.io rule, ask swmon to give you the ownership of the crate, he seems willing to do so from the crate's page.

WIP. Contact me if you want to use this name!

1 Like

Report back if you do get the name transferred. It is good to keep track of which of the squatters you can have any hope of getting a crate name from.

The problem with swmon is that they don’t provide any contact details. This 6 month old attempt appears to have had no success.

7 Likes

IMHO, a crate name shall have a lifetime too :stuck_out_tongue_winking_eye: (e.g. a year without any code upload)

1 Like

I think having a lifetime will disadvantage some crates. I'm thinking of crates that implement a standard algorithm, have solid tests and are mature and rarely need any updates.

I've also wanted to use a crate name that was in use: retest (regular expression test). My solution was to keep the name I wanted "retest" (regression/repeat test) but to use my domain as a prefix for the crate, i.e., qtrac-retest.

4 Likes

There are a lot of crate names that have been "reserved" by people such as swmon who spam uploaded empty crates. IIRC there was some discussion about tackling this but I don't know if it went any where.

The current policy on squatting is

We do not have any policies to define 'squatting', and so will not hand over ownership of a package for that reason.

There's some more detail here.

Nobody likes a “squatter”, but finding good rules that define squatting that can be applied mechanically is notoriously difficult. If we require that the package has at least some content in it, squatters will insert random content. If we require regular updates, squatters will make sure to update regularly, and that rule might apply over-zealously to packages that are relatively stable.

A more case-by-case policy would be very hard to get right, and would almost certainly result in bad mistakes and and regular controversies.

Instead, we are going to stick to a first-come, first-served system. If someone wants to take over a package, and the previous owner agrees, the existing maintainer can add them as an owner, and the new maintainer can remove them.

The proposed solution is to use "creative names" instead, the case for which is made in the " Namespacing" section:

When we looked at package ecosystems without namespacing, we found that people tended to go with more creative names (like nokogiri instead of “tenderlove’s libxml2”). These creative names tend to be short and memorable, in part because of the lack of any hierarchy. They make it easier to communicate concisely and unambiguously about packages. They create exciting brands. And we’ve seen the success of several 10,000+ package ecosystems like NPM and RubyGems whose communities are prospering within a single namespace.

2 Likes

See also the following proposals:

https://github.com/rust-lang/rfcs/pull/2614

2 Likes

Not sure if it's the right topic, but I want to also share my concern about a single namespace.

As other commented above, it have realife problems (discoverabilty of 'creative names').

One of the thing I fear is that we will have some crates not available on crates.io because the name is already taken (squatted or not) and available only using the git repository, which will fragment the ecosystem and reduce discoverability. (I plan to do this, for security reasons, I need to reimplement a lib and have to namespace it under my org, using prefix is wacky because anyone can hijack it).

Keeping this direction will greatly limit rust (or rather crates.io) adoption and scalability, especially among enterprise users where you have security requirements (to not to use random package by random people).

7 Likes

In the last few months, we already had discussions in internals forum about namespacing and both discussions went into "loops" without reaching any consensus.

Given the current scenario, the only way out is to contact the (squatted) crate owner and see if they agree to transfer the crate to you. If they, say no there isn't much you can do about it (other than picking another name).

2 Likes

I think the thing that frustrates people most is not "no" but no response at all.

8 Likes

I agree. Though that is the general thing about email communication (or any online textual communication) so there isn't much we can do about it.

If the namespace was one level deep, how would you be able to remember if, say,

  • mgeisler/libxml2 or
  • nokogiri/libxml2

is the library you want?

I think you would have to rely on the top-level entry in the namespace and so we're back to square one, no?

Basically, I imagine that you would search for the functionality you need (rust libxml2) and then you would see and remember that nokogiri is the right one. The first time you search you would need to look at both hits - but I think this is the same with a flat namespace and "creative" names?

3 Likes

What about filtering the crates by implying maintenance that would seem regular to a normal user, but not to a squatter? For example: We count the number of downloads a crate has had in the past 3 months. In the case that it is below a threshold, for example 200, then an email is sent out to the owner. This would in turn ask them if they'd like to release ownership of the crate (I'm not too sure about how ownership works on crates.io, it might just be put into a box where another user can take ownership if they so wish) and if they don't comply (By clicking a "Yes I'd like to keep this crate" button) then it is released. Just throwing out another idea, as this seems to be a very stubborn issue.

We don't know the email address for many crate owners, since this information has only recently started being collected.

1 Like

Right... I forgot about that. :confused:

Let's say I don't remember; at least I'd be able to find them.

Incidentally, I deleted that post because I decided it was going off-topic and risked derailing the thread. Hell, it's got an "Undelete" button on it for me. I really have no idea why it's still there for people to reply to... :S

3 Likes