
The Rust community's crate host - steveklabnik
https://crates.io/
======
conradk
Here is the most important part to me:

"Take care when publishing a crate, because a publish is permanent. The
version can never be overwritten, and the code cannot be deleted. There is no
limit to the number of versions which can be published, however."

That. Is. Awesome.

~~~
zrail
This has been true of CPAN for a long time, and comes as a result of it being
a network of FTP mirrors. I don't know when people decided it was a good idea
to be able to yank a package (for example, from rubygems). It just complicates
the whole setup and makes it less flexible.

~~~
steveklabnik
I can speak to the Rubygems case: you'd be surprised at how often people
publish proprietary/private information, and then need to pull it down. It
happens often enough to actually be a burden on the Rubygems team (at least,
when I used to co-work with one of them) that they left 'yank' in.

~~~
anuragbiyani
> you'd be surprised at how often people publish proprietary/private
> information, and then need to pull it down.

But once published, isn't such information already compromised for all
practical purposes ?

I can understand the legal reason behind "pulling it down" (using someone
else's IP, etc), but practically speaking the private information once
published cannot really be "undone" (at best you can make it hard to find, and
disassociate from yourself).

~~~
codexon
Let's say you accidentally published your name, address, and social security
number.

If it is only up for 1 hour, the chances that anyone malicious sees it is low.

If it is there forever, the chances that someone malicious eventually sees it
approaches 100%.

------
gramasaurous
Can anyone explain the following trend to me? I've been seeing it alot lately:
On the install page [0] the installation instructions tell people to run this
command: curl [https://static.rust-lang.org/rustup.sh](https://static.rust-
lang.org/rustup.sh) | sudo bash This seems to me to be an extremely bad idea.
Why would I want to pipe arbitrary commands into my shell? Even worse, the
shell has to run with root priveleges? Does anyone actually do this? Am I
overthinking it?

Of course, I can verify the contents of the script, but I still don't know
that the script I've verified on their website is the script that's being run
in my shell. Is it OK because the script is hosted over https, and therefore
can't be modified on transmission?

[0][https://crates.io/install](https://crates.io/install)

~~~
sschueller
Does curl return a partial output if a connection dies?

What if it dies and the last thing it got was "rm - fr /" but not the rest
after the / ?

~~~
aidanhs
Never thought about this, interesting question.

You can try this equivalent, killing the server when it tells you to -
[https://gist.github.com/aidanhs/e40417381e9aecb87b35](https://gist.github.com/aidanhs/e40417381e9aecb87b35).
It prints '/', i.e. would remove your root directory if it was an `rm`
command.

Won't be doing that again then.

~~~
steveklabnik
Remember that these days, with GNU rm, you have to pass in `--no-preserve-
root` to actually `rm -rf /`. Attempting to remove something in the home
directory and getting a `rm -rf /home/username/` would still be pretty bad.

------
dherman
Announcement and details are here: [http://blog.rust-
lang.org/2014/11/20/Cargo.html](http://blog.rust-
lang.org/2014/11/20/Cargo.html)

------
vog
I'm a bit disappointed that this whole site works only with JavaScript
enabled. No graceful degrading or anything. With disabled JavaScript, the page
is just empty.

------
kibwen
I was happy to discover that the backend is written in Rust as well. Here's
the code for anyone who's curious: [https://github.com/rust-
lang/crates.io/tree/master/src](https://github.com/rust-
lang/crates.io/tree/master/src)

~~~
aalvarado
At first I saw that ember-cli was being used and wondered if the backend was
done in JS. I came to the same realization as you.

------
snfernandez
Great work. Only one improvement I would like to see 1) Switch the web design
away from javascript (at least for loading) or, 2) Implement some command line
interface in cargo for searching crates and displaying it's description.

~~~
steveklabnik
Command-line search would be cool, for sure. Submitted!
[https://github.com/rust-lang/cargo/issues/925](https://github.com/rust-
lang/cargo/issues/925)

~~~
yuriks
What about requiring JavaScript even for the bare minimum of functionality?
(That is, even loading the main page.)

~~~
steveklabnik
I would agree with adding some <noscript> tags to at least print a message
telling you to turn it back on, sure. Filed: [https://github.com/rust-
lang/cargo/issues/931](https://github.com/rust-lang/cargo/issues/931)

------
mmerickel
Am I correct in assuming that this is focused only on source distributions
right now?

~~~
steveklabnik
That's correct. Rust doesn't have a stable ABI, so you'd have to have the same
exact compiler revision as the one it was built with for it to work. And
that's just the first issue...

------
alanD84
It's very impressive. I am concerned that it requires enabling scripts from
google.com to even show any content. Mozilla has shown it actually cares about
user privacy so I hope they address it.

~~~
steveklabnik
I already spoke with someone who is sending a PR to fix this, so hopefully
that will not be true soon.

~~~
alanD84
That's great. To be honest I really didn't expect a response for such a
pedantic complaint. Most people accept a world where Google touches everything
with its JavaScript and font CDNs etc. The site looks great and I'm really
enjoying working my way through the Rust Guide at the moment.

~~~
steveklabnik
I am, uh, very excited for this launch. :) (and glad you're liking the Guide
too, please open issues if it can be improved)

------
blm
For me the ability to use packages made by other people is a draw card for a
language.

However, when I first went to the site, all I could think was "Whats a crate
in relation to programming or more specifically Rust? Is it Rust's idea of a
package (eg like ruby gems)."

I just think it would be good to have the site say Cargo: The Rust language
package manager.

The site also says this:

"The Rust community's crate host". Is it not a cargo host for distribution of
crates where crates are Rust packages? Is there non-community crate hosts?

~~~
steveklabnik
Basically, crates are packages, yes. It might be good to add some non-jargon-y
copy there too, yeah. :)

------
demarq
If you aren't cool with me using your code, I respect that. I don't like
forcing people to give up anything including their rights to their own repo.

I just don't feel comfortable working on someone's code if they aren't
willingly consenting to it. just not cool at all! Human consent is just not a
permanent thing.

Besides if the file disappears from the remote source, you can still build for
the time being. It's not the end of your project, but it may be the end of
someone else's career - you never know what reasons people had. Just respect
peoples rights over their data.

The constant argument, "it's already on the internet" doesn't absolve any of
us, from respecting peoples reservations. And if it's "already on the
internet" then you can trust that someone will illegally copy and repost the
repo on-line but where does that leave us ethically?

not the way I roll.

~~~
wyager
That seems like a very extreme view of intellectual property. "Intellectual
property rights should be so strong that you can retroactively censor data you
made freely available."

~~~
andrewflnr
The Right To Have My Work Forgotten. Yeah, I don't think Right To Be Forgotten
makes any sense either.

------
jonalmeida
I'm really looking forward to publishing some early crates! A cargo search
from the terminal would be ace as well.

~~~
steveklabnik
You're going to want to subscribe to [https://github.com/rust-
lang/cargo/issues/925](https://github.com/rust-lang/cargo/issues/925) then :)

------
thom_nic
Second most downloaded: brainfuck_macros

~~~
desdiv
_A compiler plugin that converts brainfuck code into Rust at compile time,
letting your BF programs be optimised by LLVM to super-fast native code._

------
losvedir
Hooray! This has been eagerly awaited in the rust community for a while.
Thanks, Steve!

~~~
steveklabnik
Basically zero of the thanks should go to me. Alex Crichton has been hard at
work on this for the past while, both Cargo itself as well as the site.

~~~
losvedir
Ah, then: Thanks, Alex!

But fortunately "thanks" aren't zero-sum, so I'll leave your ill-gotten gains
alone. :p

------
mrinterweb
I'd love to see categories added to crates.io kind of like ruby-toolbox.com.
Categories as well as repository activity information is helpful for
discovering libraries that will suit your needs. Since there are so many ruby
gems, it is now hard to properly categorize gems, and ruby-toolbox doesn't do
the best job of this anymore. I found it to be very helpful years ago. Ruby-
toolbox is still helpful in that it can show some similar projects and show
project activity to help you see which projects have more momentum.

~~~
steveklabnik
If you look at each project's page, for example,
[https://crates.io/crates/gl_generator](https://crates.io/crates/gl_generator)
was the first when I loaded up crates.io, on the right there's a "Keywords"
section.

~~~
mrinterweb
Fantastic. Not sure how I missed that.

Edit: There are plenty of crates not categorized, and that must be how I
didn't see this feature.

------
veqz
But how does one avoid having crates.io being flooded by bad/useless crates?

And couldn't the same crates end up occupying all the "good" crate names?

~~~
steveklabnik
In theory, this could happen. In practice, Ruby/Python/JavaScript seem to be
doing just fine.

~~~
fjafjoafjlw
Have you guys given any thought to namespacing packages by developer, like
Github. I've had to rename a couple of my own Python packages before uploading
them to the package index to avoid naming collisions, so it definitely becomes
an issue once the repository hits a certain critical mass.

I assume Rust will be around for a while (I certainly hope so - I've just
started learning it!) so it might be wise to plan for growth now before it's
too late to implement.

~~~
steveklabnik
It creates a significant amount of complication. When I'm writing a blog post
or documentation or in conversation, how do I differentiate between your foo
and my foo? When I 'extern crate foo' in my source, which foo should it use?

While it's true that sometimes collisions happen, in practice, you just choose
a new name. Everything is significantly simpler, which in software is very
often a Good Thing.

~~~
fjafjoafjlw
I can appreciate that it adds complication to the implementation. I don't
think identifying a particular crate would be an issue though, any more than
identifying a particular repository on Github is. It's easy enough to talk
about jdoe/foo if there's any danger of ambiguity, and links are definitive by
their nature.

Just from my own experience, I know that it makes me less likely to make
packages public if I have to give them odd, collision-avoiding names first -
especially as I then have to use those names myself. It's particularly
annoying when the incumbent package is 10 lines of poorly-written abandonware
that hasn't been touched in years, which often seems to be the case.

I know this isn't an issue for Rust now but I'm thinking about ten years down
the road when you have 250,000 crates on the site, 99.9% of them junk,
clogging up that flat namespace. (Python's repository has more than 50,000
packages and seems to be growing at an accelerating rate now that it finally
ships with a decent package installer by default.)

~~~
steveklabnik
> I don't think identifying a particular crate would be an issue though, any
> more than identifying a particular repository on Github is.

Nothing is impossible, of course, but the language already has a flat crate
namespace. So you could either implement some kind of layer on top of that, or
change the language itself to have some sort of crate hierarchy somehow. All
just to have two crates named 'http' rather than one named 'http' and one
named 'requests' (for example.)

Here's another way of looking at it: shipping a flat namespace is a proven,
well-worn solution. Adding in a hierarchical one, on top of the language,
which has a flat one, provides dubious benefit, for significant implementation
complexity.

~~~
fjafjoafjlw
Meh, if I wanted a 'proven, well-worn solution' I'd use C++. I want you guys
to sprinkle fairy dust on my code and make the experience magical ;)

Seriously, I do get that there are trade-offs. I'm just interested in how
you've been weighing up the alternatives as I do often find myself wishing
that other projects I've been involved in had taken the hierarchical approach
at the beginning when it was an option.

------
thristian
Does cargo support alternative package repositories? For example, at $EMPLOYER
we have a DevPI[1] installation, so company-internal packages can be shared
between employees as easily as public packages can be shared with the Internet
at large.

[1]: [http://doc.devpi.net/latest/](http://doc.devpi.net/latest/)

~~~
steveklabnik
Yes, you could grab all this code off of GitHub, spin up your own instance,
and then set up your `.cargo/config` file to point at your copy, and it Just
Works.

~~~
wilmoore
I really wish it would also allow `~/.config/cargo/config` just like
`~/.config/git/config`.

~~~
steveklabnik
I believe there is an open ticket to follow the XDEG specification or
whatever. You may want to find and :+1: that.

------
demarq
This will certainly make our lives easier.

BUT.

1) Why store a package, wouldn't an index rather than another repository be
more efficient and flexible.

Cargo already has the capability to get packages from git urls...

I had some other nicks but I see this is on github so I'll try and contribute
there.

I like the site, and can't wait to test it out. Thanks to all who have been
working hard on this!

~~~
mercurial
> 1) Why store a package, wouldn't an index rather than another repository be
> more efficient and flexible.

I suppose the authors experienced the "guy deleted his Github repo" effect one
time too many. It's a very sensible decision. Getting packages for git urls is
fine when you're hacking something together, but there is absolutely no way
I'd put anything in production relying on something that fragile.

~~~
demarq
I think it's even worse depending on a repo whose author refuses to or is
unwilling to maintain.

Besides git is hardly fragile especially if we are talking github. I happily
clone and pull projects all the time without a single hitch. Also if you think
about it github/attlassian are all dedicated to task with datacenters around
the globe, while for the rust team the repo _might_ be somewhat of a side gig.

~~~
mercurial
I'm not so worried about Github going down as I am about people removing their
repos.

And why do you think depending on a repo is worse than depending on Github? If
the package is not maintained anymore, license willing, you can always fork it
and bump the dependencies yourself, even if, in the worst of cases, you need
to keep the fork local. However, if it turns out you have to maintain a lot of
third-party libraries yourself, it's a sign either of a bad ecosystem, or that
you picked the wrong libraries.

~~~
demarq
I guess at the end of the day so long as cargo has the git option people like
me will always get our code fresh from the source, with the maintainers
consent. It's not like I'm being forced to use the crates-repo.

Let's agree on one thing we shouldn't be maintaining other peoples
abandoned/illegal libs, however thanks to them being posted on the crates-repo
permanently, we'll continuously keep running into them...

~~~
mercurial
> Let's agree on one thing we shouldn't be maintaining other peoples
> abandoned/illegal libs, however thanks to them being posted on the crates-
> repo permanently, we'll continuously keep running into them...

Maybe. But at least, if you pick your or somebody else's unmaintained code
from five years ago, you have a fighting chance of making it compile and run.

------
kiliancs
Maybe it's just the very beginning but I would really like to see detailed
descriptions for every crate as well as links to the website or repository if
available. It's just hard to understand what they do, how they do it and their
quality.

~~~
steveklabnik
Yesterday, we implemented a warning if your description and/or license aren't
filled in when you upload a package. And 'homepage' is also possible too,
authors just have to put them in.

~~~
untothebreach
small nitpick: 'homepage', not 'website'

~~~
steveklabnik
whoops, edited, thanks

------
hello_there
Cool. It would be nice if there was a link to each package's web site or
source code.

~~~
steveklabnik
If authors give us that metadata, it appears on the site.

------
AndrewGaspar
FWIW, the page is a bit messed up in IE11 on Windows Phone:
[http://1drv.ms/14VI93Z](http://1drv.ms/14VI93Z)

Awesome work!

~~~
steveklabnik
Filed! [https://github.com/rust-
lang/crates.io/issues/56](https://github.com/rust-lang/crates.io/issues/56)

------
EdSharkey
Sweet, let's build an OS based on Rust code now!

Why don't we port something that's already got an eye for security, like
Minix?

~~~
steveklabnik
There's already a few projects doing so. Drop by #rust-osdev on Mozilla's IRC
network sometime. :)

------
unfamiliar
Why is cargo not bundled with my rust install?

~~~
killercup
rustup.sh installs both.

For other install methods see: [https://github.com/rust-
lang/rust/issues/16456](https://github.com/rust-lang/rust/issues/16456)

------
untothebreach
Congrats on shipping, cargo team!

