View source on site

[bvssvni]

Currently you have to do something like this:

curl -OL https://crates.io/api/v1/crates/curl-sys/0.1.0/download
tar -zxvf download

What I want to do, is to view the source on the site in the browser, if possible.

[ghost]

I'm skeptical about this. crates.io will already include a link to the GitHub page for many of the crates and that seems to offer the best experience for browsing through the code. I don't think crates.io should be in the business of reinventing that experience.

What would definitely be helpful, however, is having crates.io cross-reference inidividual crate versions and their corresponding GitHub tags if possible.

[ghost]

In any case, this bug should be filed under https://github.com/rust-lang/crates.io, though again, I would personally reconsider the scope of this issue to be more focused on how crates.io interoperates with GitHub rather than proposing a greater overlap of features.

[bvssvni]

What I thought of first was a git commit hash, but that doesn't work very well since you have to change Cargo.toml to publish when working with git dependencies.

[diwic]

Well, I think we need something. Right now I believe it is entirely possible to publish something on crates.io that does not have a github repository at all, and then there is no discoverable way to get the source. Even just a link to download the tar archive (as written in the topmost comment here) would be helpful.

Or we could make github mandatory, but then you should not be able to publish anything without a proper repository key in Cargo.toml.

[marcusklaas]

Making github mandatory seems like a dangerous decision. This could make github too
indispensable for the Rust language. Its function should ideally not be tied to the faith or whims of a single organization, however benevolent.

[diwic]

It would also help security if there was a "source view/download" button IMO. It's easy to sneak bad code into a crate and publish it, and the more possibilities for malicious code to be detected, the better. I'm not entirely sure where the code is compiled though - is it compiled for all platforms on the crates.io server? Or is the source downloaded and compiled locally, and if so, how does one find the source locally?

[nagisa]

This would be mostly fixed by rust-lang/crates.io#91 since the generated documentation already provides a way to see the source.

[bvssvni]

@diwic The source is downloaded and compiled locally.

[withoutboats]

It's good to know about the workaround at the top of the page (it solved the problem that brought me here), but this doesn't seem like a non-issue at all to me. Getting a readable source from crates.io is not accessible, even though its the code on crates.io that is compiled and depended upon. It isn't particularly important in my opinion if its available on the site or as a documented cargo command or some other method, but the source of crates available through cargo should also be available through cargo or crates.io.

Nothing about crates.io or cargo requires or particularly encourages users to create and maintain a public repository for the source of their crate. Of course, distributing the source is essential to free and open source software, so it seems quite bad to me that cargo enables users to neglect that aspect of distributing their projects.

I found this issue while trying to access the source of a crate which has a repo on GitHub, but the head of the GitHub repo is more than 3 months behind the version on crates.io. This problem is not theoretical.

[BatmanAoD]

If nothing else, it would help if the GItHub link (when there is one) were a little more prominent. Putting it in the midst of a list of other arbitrary "links" near the bottom of the page is a bit confusing.

[carols10cents]

Would a command called cargo-open that opens the location on your filesystem that a dependency's source has been downloaded to in your $EDITOR meet the needs described in this issue?

[alexcrichton]

@carols10cents yeah I'd consider something like that to fit the bill here basically. I think of this as basically making it convenient to download source from crates.io and explore it.

[durka]

It would still be great to have a way to get the source on the site without having to create a cargo project and add a dependency. It could just be a download link, not an online viewer.

[diwic]

How difficult / resource draining would it be to run cargo doc for crates when they are uploaded and add a link to that? Not only would that give you fresh and up-to-date documentation, but they also have source links.

It seems fairly straight-forward to implement (with a caveat for crates that are different depending on arch, as well as sandboxing build scripts). I just don't know enough about web development to know what kind of load such a server would require.

[withoutboats]

It would still be great to have a way to get the source on the site without having to create a cargo project and add a dependency. It could just be a download link, not an online viewer.

Yeah, though I think the best solution to this is probably a cargo source command which takes a crate name as an argument, rather than a link on the crate pages on crates.io.

[JanLikar]

https://github.com/janlikar/cargo-clone Check this out!

[durka]

@JanLikar great!!

On Tue, Jan 26, 2016 at 8:12 PM, Jan Likar notifications@github.com wrote:

https://github.com/janlikar/cargo-clone Check this out!

—
Reply to this email directly or view it on GitHub
#1054 (comment).

[carols10cents]

I think between cargo-clone, cargo-open, github, and docs.rs, we've got enough options for this. Please reopen if you disagree!