I was reading the blog of the “reqwest” author and one of the sub points was this:
The odd name is an unfortunate consequence of being late to the party. The request crate is effectively abandonware. I’ve tried reaching out to the author in various ways, but he seems to have disappeared from the internets. The requests crate (with an ’s’) also exists, but does seem to be actively developed.
This is bad. Bad for developers as it makes it difficult to remember which crate you should be using, bad for the community as it lets people abuse the package manager, and bad for the individuals who create crates because it puts a requirement on them to always be active and doesn’t allow them to abandon work if they don’t want to do it anymore.
I want to propose two things:
- Add a way in Cargo to “give up” your crate name. Essentially this will delete all versions already on it and make the name available for others to claim.
- Also add a way to open a ticket to gain ownership of a crate name. That crate has to have very few downloads over some time period (say 6 months) and have no new updates. If either of these are true, you can request to gain ownership. If you do, all maintainers will receive several emails over a couple of weeks which will allow them to keep the name. If not, the name will be transfered.
- Under very rare circumstances, it should be possible to transfer a name for the good of the community. Such a name would include the “request” crate if that became necessary.
I have been the cause of this problem before, where I created a crate called rst for my requiremrents tracking tool, forgetting that it was a common name for the ReStructured Text format. In my case, I gave the name over – but it doesn’t always turn out that good
- allows crates that are core to the community to be maintained in any eventuality
- allows for names that are common within other communities (i.e. python) to be used within the rust community, making it easier for newcommers
- reduces confusion within the community (like having 3 names for the request module but only one is maintained).
- without some process in place, we are susceptible to what happened to node.js – in particular cargo DOES allow the maintainer to unpublish versions (maybe this ability should be removed? Possibly separate question)
- depending on implementation, may increase strain on crates.io maintainers
- could cause strife within community, especially if someone feels that the process is unfair
- time limits are difficult to determine with any evidence-based approach, decisions may be somewhat arbitrary.
- added advantages and disadvantages