I'm not sure what's the next step in the process. Does it need an RFC? Does it need fleshing out more details? Or is it the time to code it and make a pull request?
Personally I'd think an RFC is necessary, but ultimately it would be up to the crates.io team.
I think there are still open questions (like how long a reservation lasts, if and how much you can renew it, what happens in search results...), and I think a RFC would be the best way to address those.
The following might approach bikeshed territory. In programming languages “reserved” can have various meanings. I think to the casual user the words “this crate has been reserved" might not convey the right meaning: it hasn't been reserved by the crates.io team but by some individual, and the reservation might lapse. Can we use a different term? booked, claimed, retained, saved, etc.
The only concern I have is that this approach might have an anti-chilling (heating?) effect on squatting. By implementing this change you demonstrate that reserving a name for your crate is acceptable, so reserving one hundred crate names must be acceptable as well.
I know I've seen established convention for what word to use here but, for the life of me, I can't remember what it was.
The closest I can think of is "worsen" or "fan the flames of".
I think the first optional should be mandatory. Otherwise you can reserve the name indefinitely and go die off somewhere and nobody will be able to use the name until the crates team decides to do cleanup.
The second optional just makes squatting ok: I reserve the name, you can contact me if you want to know how much you need to pay me to let you use it. That is bad on one side, because it doesn't allow people who want to publish a real crate under a given crate name and good on the other, because the squatter is likely to use this feature instead of publishing an empty crate, which means no polluting the registry, which means smaller registry and faster
This is why I personally think there should be a maximum number of names you can reserve, even in the MVP of this.
I also agree the "dead man's switch" / having an expiry date should be mandatory for the MVP too.
But with those limits in place, I'm all for this.
I think reserved crate names should also have the ability to set/edit standard metadata, such as readme files, license info, author, source code url, etc. See algebraics v0.0.2 for an (admittedly rather sparse) example.
I disagree, maybe aside from source URL so people can check on the progress. A reserved name inherently has nothing useful, so what would the license, README, author, etc. even be with regard to?
The reserved name can be more than just a name, it can also be an opportunity to increase awareness of the crate that will be published, so it should be able to include information about what will be published such as description, code license, source code url, project url, readme -- basically a lot of the stuff in a normal crate except actual source code.
But who's to say that it'll actually be published in the future? Lots of times projects fall through; it happens, and people understand.
If you've got a license & other things, it literally applies to something that doesn't yet exist. To me, that doesn't make sense. Like I said, a link to the repository would be fine, as that could contain the relevant information, but anything beyond that is information about something that doesn't exist on crates.io at that moment in time.
I guess basically what I'm saying is that the proper way to raise awareness is via the link to the repo and by other means, like posting on Reddit or Hacker News. Raising awareness on crates.io would be a bit misleading, since the crate can't actually be installed from there.
Regarding squatting on crates, the price of owning a namespace should be in the usefulness of the crate to the community. Some of us feel like we paid that price with our time, effort and charity to others, and we sort of expect much the same from others.
I like your "publish or perish" idea, but would suggest dwindling renewals (6 months, then 3 months, then 45 days, then 22.5...) so that the squatter has to do ever more work and still couldn't create infinite ownership. Possibly revoked crates could just migrate to a longer less populated namespace so if user "greedy" created a "sexy" crate they could still access the crate at "zzzzzz_greedy_sexy."
And I'd suggest revoked namespaces be made available after a random number of days only to users with a prior history of active crates and no namespace revocations in the last 24 months.
A monthly rental fee offered after 6 months of empty & inactive or "flagged as squatting" with funds contributed towards a rust language non profit might likewise be a reasonable thing to do. Useful functional crate within 6 months of name reservation - utility price paid, yours mostly forever more. Vaporware? Thank you for supporting the Rust Language and its community at the $1 per month or $12 per year per seemingly useless crate level. Maybe Boats and Niko can get a new pair of shoes.
And I'd suggest that namespaces of a certain length really don't yet need to be part of any cleanup effort. I'm looking at you "myfirstlibrary." Everyone starts somewhere and should be allowed to learn rust and make mistakes at whatever pace they need.... And a 14 character namespace barrier to entry for first timers doesn't seem especially high.
It is highly unlikely we will be adding any sort of payment system to crates.io. For one, that would add a barrier for people without a credit card, which we don't want to do. For another, no such legal non-profit entity with a bank account currently exists to accept the funds, and creating one is nontrivial.
Beyond that, as soon as you start to accept money, the laws get much more complicated.
Over on Phoronix, there was a fairly lively argument over whether the Flatpak people realized how much potential legal obligation of the "consumer rights laws/non-waivable" kind they were setting themselves up for by preparing to offer an internationally accessible "protected/authenticated downloads" mechanism linked to a payment system.
(I'm worried about the concept of such vaguely defined "protected/authenticated downloads" for other reasons, but that's irrelevant here and easily solved by giving up my advocacy of Flatpak in favour of a more ethically opinionated vendor (eg. The Debian Project for non-games and GOG.com for games) and a more manual sandboxing solution, like Firejail.)
Not necessarily, it isn't available from crates.io but it is still useful information that can guide a prospective user to use the git master until a crates.io release is made rather than passing over it in favor of something else.
To me, if you have an entry that someone found by searching on crates.io, wouldn't it make sense for there to be some information about what they found, without having to click a link and visit some other website? If there isn't information immediately visible, it can deter potential users. As an example, I totally miss lots of good software just because it didn't stand out the first time I saw it.
I agree, hence why crates.io would probably not be the place to send everyone who found about it some other way, however, if they found out about it at crates.io, then they should be able to easily see details of what they found without needing to click on a link.
Is this ("I have code on GitHub but haven't pushed it to crates.io yet") really the expected usecase for such a feature? I had imagined that this would mostly be used for people who have thought of a name and an idea, but haven't written the code yet.
I thought it was very easy to publish a crate, so it seems unlikely that people will be at the stage of "code on GitHub but not on crates.io" for very long – and it also seems unwise to encourage code to exist in such a state.
I had assumed the opposite: that it would mostly be used for "I'm in the middle of writing something but it's not ready yet and I'd rather not rename it in case someone else takes the crate name".
Ok, though personally, I won't publish something on crates.io until I've decided on an API and implemented most of it. If the whole API is not needed, the parts that are finished can certainly be useful to other people before it's published.
To me, publishing something on crates.io is basically saying that it's ready for everyone to use it, even if I haven't fixed all the bugs yet.
You guys do such great work! I appreciate the critical searing feedback just because I think team rust is awesome! I think rust will succeed & grow wildly.
Anyway, my thinking was mostly along the lines of how can bad behavior itself be discouraged. And i offered up mostly brainstorming for behavior shaping. Publish or perish with up to a year grace period before unused assets return to community ownership doesn't seem especially unreasonable, but might, perhaps, prevent a graffiti'd or squatting namespace gold rush. And long character "?lower value? namespaces for learning how to write crates and buildskills is an idea that might make sense in a decade if rust had millions of crates.
Curation is painted on crates.io very thinly... A few years back I looked for a sorting crate because my "i'm learning rust" bivariate sort code was terrible. The first one I found was clearly intended as a joke. I fear for the quality of rust first introductions as the user base grows. Rust's community is something special.
Nonprofits - yea, my wife works for one - thanksgiving included 3 hours directing traffic and trying to keep cars from hitting Turkey Trot runners - sheer madness!
Good luck... you deserve a new pair of shoes too! Cheers, - Dustan Doud
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.