Cargo is super useful when it comes to building and dependency management.
But what if I just want to build some binary crate (not a library) from repository?
Is there a way to say something like "cargo bin pulldown-mark" for recent pulldown-mark crate and get a runnable binary, without need to clone repository, cd to it and run "crate build" in there?
Also, is there a way to get sources from crates.io, with e.g. "cargo get {crate-name}" or something?
Source:
Cargo downloads the source code to ~/.cargo/registry/src/, but be careful before interfering.
Binary:
You mean like pip for python? Seems interesting.
https://github.com/rust-lang/cargo/issues/37
aaaand i thought the second had an issue, maybe it doesn't
Thanks for point out the issue, I remember I saw it somewhere, but forgot about it since then.
I just hoped something changed in this regards since stable release.
I'm actively waiting on this feature too 
The stable release was primarily about Rust language semantics. If anything, work on the stable release prevented this kind of extra functionality from shipping, since the focus was on language semantics and not this kind of thing.
I guess I'm not the first one to create shell script to build package from crates.io, but I haven't seen one here.
Anyway, I hope it will help someone, until cargo gain enough power to do this job:
cargo-build is a really bad name for this: if you run cargo foo, cargo will search the PATH for a program called cargo-foo and run that. Presumably, it won't run your script over the "real" cargo build subcommand, but it still seems like a bad idea.
Actually, I think something like this might be a useful addition to cargo-script; perhaps I could add a --crates-io flag, or make the input path accept crate: pseudo-urls for the job.
Now, that said, I do wonder about one thing: do we even want binaries in crates.io? I mean, I was under the impression that the major point of putting a package up there was for libraries. I know some libraries happen to have binaries... but what about something like cargo-script which is really only useful as a binary? Does it have any reason to be on crates.io?
Now, that said, I do wonder about one thing: do we even want binaries in crates.io?
Why not? Since Cargo.toml allows us to describe binaries asking with libraries, why shouldn't we be able to put them to crates.io? If we are disallowed to put binary crates to crates.io, then we should be disallowed to define [[bin]] sections as well.
To be blunt, that line of reasoning is asinine. You're saying that if crates.io doesn't support binary packages, then no one should be allowed to build binaries with cargo, ever.
I asked the question because currently, if you put a binary-only package up on crates.io, you can't really use it. It's not a library, so you can't depend on it, and there's no obvious way to fetch and build it. At no point did I say crates.io shouldn't allow binary-only crates, I was merely wondering whether it makes sense to build out support for them there as opposed to somewhere else.
For example: Windows users typically want pre-compiled libraries that come with binary dependencies. Linux users may want to install stuff via the system package manager. Does it make sense to have crates.io handle this as well, or does it make more sense to build something else?
I don't know, just wondering.
I agree with you on this point, but I couldn't think of a better name for the script. It's not important in this case, anyway, as it's just a gist's name, and you can name the script whatever you want, when/if you install it to your system.That said, you have some better name for the thing it does?
Sorry, seems like we misunderstood each other. Yes, I agree on the fact, there's a problem with binary crates in crates.io. Maybe there should be some kind of tag/mark/whatever for binary-only crates?
True, but I think it would be very handy if cargo / crates.io could work the same way as npm for binaries.
As a centralized repo where you just have to do cargo install package or cargo -g install package to fetch and build the latest version locally or globally. And that independently of your OS.
I think it would make it a lot easier to share smaller projects without the need to host your binary personally on some obscure personal website or asking someone with no programming knowledge to compile from source. I know it's really easy to compile from source with cargo, but something like cargo install package would make it even easier. 