rust-lang / docs.rs Goto Github PK

It would be nice to have aliasing (through the use of, say, symlinks) for the latest version, so we could point the README of a project to https://crates.fyi/crates/cratename/latest/.

It appears my package can't be compiled because of the outdated version of rust nightly. I checked the logs here and someone in IRC suggested this was due to nightly being old.

Looks like it should return a random crate

It would be nice if the versions of a single crate could be sorted numerically instead of via string comparison, i.e. that we don't get '1.1 < 1.10 < 1.2' but rather '1.1 < 1.2 < 1.10'.

E.g. the current version of arrayvec isn't immediately obvious from the directory listing:

0.1.0/                                             13-Feb-2016 15:27                   -
0.1.1/                                             13-Feb-2016 15:27                   -
0.1.2/                                             13-Feb-2016 15:27                   -
0.2.0/                                             13-Feb-2016 15:27                   -
0.3.0/                                             13-Feb-2016 15:27                   -
0.3.1/                                             13-Feb-2016 15:26                   -
0.3.10/                                            13-Feb-2016 15:25                   -
0.3.11/                                            13-Feb-2016 15:25                   -
0.3.12/                                            13-Feb-2016 15:24                   -
0.3.13/                                            01-Feb-2016 05:55                   -
0.3.14/                                            06-Feb-2016 00:34                   -
0.3.15/                                            06-Feb-2016 19:37                   -
0.3.16/                                            29-Feb-2016 23:32                   -
0.3.2/                                             13-Feb-2016 15:26                   -
0.3.3/                                             13-Feb-2016 15:26                   -
0.3.4/                                             13-Feb-2016 15:26                   -
0.3.6/                                             13-Feb-2016 15:26                   -
0.3.7/                                             13-Feb-2016 15:25                   -
0.3.8/                                             13-Feb-2016 15:25                   -
0.3.9/                                             13-Feb-2016 15:25                   -

For example, if someone publish a crate named releases or about (which currently doesn't exist), their docs should be served in https://docs.rs/releases and https://docs.rs/about respectively right? But currently those page was used as a listing and about page.

Possible solutions: move those internal page under something that isn't a valid crate name.

EDIT: https://docs.rs/about/0.1.1 already exist.

Try https://docs.rs/libloading/banana/

Examples:

• https://docs.rs/url
• https://docs.rs/URL (leads to crate not found)
• https://docs.rs/Url (leads to crate not found)
• https://crates.io/crates/url
• https://crates.io/crates/Url
• https://crates.io/crates/URL

Crates who share names with other projects on github link to incorrect star numbers. Ones such as the docopt crate, which links to the docopt/docopt project, instead of the docopt/docopt.rs project.

https://docs.rs/releases/stars

It looks like the latest version of the futures crate (0.1.1) is not showing up: https://docs.rs/futures

For example: iron-0.3.1 was released more recently than iron-0.4.0. Therefore, the default version linked to on docs.rs is 0.3.1, when the highest version is actually 0.4.0. It would make more sense to default to the highest version number.

On the crate page there seem to be no link to the same crate on crates.io. I think there should be one. Maybe add it to the Crate/Links section?

Thanks for making a great service.

Here's a tricky one:

itertools 0.5.0 reexports either::Either from the either crate. The either crate has correctly and neatly set up its doc(html_root_url) to point to its docs.rs page.

itertools::Either on docs.rs: https://docs.rs/itertools/0.5.0/itertools/enum.Either.html

The [src] link from that page is cross crate: https://docs.rs/either/1/either/enum.Either.html?gotosrc=10

And it does not resolve correctly, it ends up with redirecting to https://docs.rs/either/1/either/undefined

Being in some module and then attempting to switch to a different platform (try unknown-linux-gnu) throws you back to the root of documentation.

It would be nice if an attempt was made to not forget the module user is in when switching the platform.

A naive implementation strategy could be something along the lines of: Given an URI like https://docs.rs/{crate}/{version}/{platform}/{...path} try to load https://docs.rs/{crate}/{version}/{new-platform}/{...path} and if that fails, load the crate root documentation.

It can be useful for adding some custom JS libraries like KaTeX

Relevant issues:

• rust-num/num#225
• libOctavo/octavo#90

Upgrade the searching algorithm to something more flexible, like Eudex.

It would be nice to have a way to refer to some module in version-agnostic manner (in, say, README), so it gets redirected to the newest version available.

My use-case is always linking to the most recent changelog which I maintain as a module in rustdoc.

Docs.rs' badge handler started sending CacheControl header since c97a95a. Some projects started using docs.rs badges before this commit and GitHub's image proxy service camo cached this badges for an unknown time period. This badges needs to be purged from camo, and then docs.rs badges can start working properly in GitHub.

If you started using docs.rs badges before 3rd September or your badge keeps showing an old version, you can simply PURGE badge from GitHub's proxy server with:

curl -X PURGE {camo-url-of-badge}

It looks like the weight for strong is overridden in docs.rs. This removes emphasis that may be present in the crate docs.

It expired on 2016-05-01.

If crate's git repo is hosted on github docs.rs shows projects stats fetched from github.com. This ticket is for having similar arrangement for gitlab.com as well

Docs.rs may have failed to build some crates for various reasons (missing dependency on build machine or bad configuration etc).

You can report them into this issue.

For example, instead of linking to https://crates.fyi/crates/geojson/0.1.1/, I could link to https://crates.fyi/crates/geojson/latest/ which will redirect to https://crates.fyi/crates/geojson/0.1.1/. Then, everytime I update a new version, I don't have to update documentation links.

Some crates, in particular winapi, will have dependencies in the form of foo = { version = "0.2", path = "some/where" }. Building such crates from a git checkout is fine since all the path dependencies are in the repo and can be found. Building such crates from crates.io is also fine, since even though the other crates aren't in the archive, cargo will only use the versions from crates.io to build it and not the path dependencies. This pattern is useful as it allows rapid iteration of interdependent crates, while still allowing it to be uploaded to crates.io.

When built on crates.fyi, it is working with the archive downloaded from crates.io, and then attempts to build it with path dependencies, resulting in build failures as it looks for the other crates in locations that don't exist.

Some examples:
winapi and its failure.

Could not find `Cargo.toml` in `/home/updater/winapi-0.2.7/lib/runtimeobject`

kernel32 and its failure

INFO - LocalDependencyIoError(Error { repr: Os { code: 13, message: "Permission denied" } })

On the "Crate" tab, I love the link to the author in the sidebar, and I love that the author link goes to a page listing all the other things that person has authored.

What I'd really like is the same thing for "owners" in crates.io, basically this crates.io issue.

For example, I'd love to be able to see all the crates that the pistondevelopers github organization is listed as an owner on. This would let me discover crates that are officially supported to work well together, as well as find other crates by authors who I trust.

Hi, I would like to use crates.fyi for the documentation of my package unicorn-rs. Could you add it? https://crates.io/crates/unicorn.

Thanks,

Sébastien

Some crates (google-*) failed to build with an error:

2016/09/11 15:38:19 [ERROR] cratesfyi::docbuilder::queue: Failed to build package google-licensing1-cli-0.3.6+20150901 from queue: the given version requirement is invalid

google-* crates are using a versioning scheme like: 0.3.6+20160617. cratesfyi's build_doc cannot handle this version string.

Corresponding crates.io issue: rust-lang/crates.io#381

Imagine you're browsing the slightly outdated docs of some project: https://docs.rs/regex/0.1.75/regex/

There could be a small badge that's visible in that case (maybe yellow or orange) that lets you jump to the current version (“Version 0.1.77 is the most recent release”).

It's important for this feature that the badge is not shown if you're already at the newest release.

Versioned links are going to be very useful, but this could be a small help if you have users arrive to stale docs via old links without them being aware of it.

Right now, [src] links in docs point at rustdoc-generated source listings such as this one. Given that docs.rs has its own native source tree browser, those links should point to that instead.

Currently cratesfyi is using a much older version of rustc, and so some projects which rely on those features aren't working.
Example

It would be really useful if there was a link to the (github) repository from a crate's page on docs.rs! Maybe they are there somewhere, but I can't find them.
Those would improve usability quite a bit and stump me as a user a lot less in my flow, if I didn't have to leave the docs.rs page in order to check out a crate's GH page!
(It's very nice though for some use cases I imagine that there is a "source" tab already integrated in docs.rs! Keep up the good work!)

When pressing ? the whole page is blur, a little error in the css I supposed

The Markdown reference style link syntax seems to not be recognised by whatever you use for crate information page (where the README is displayed).

A Markdown reference style link looks like this:

[I'm a reference-style link][link]

[link]: example.org

This issue breaks README's like mine.

It wasn't immediately obvious on how to switch between versions of docs until switching it via the "Crates" tab.

Hence, I think it might be more convenient to switch between versions via a dropdown menu. This dropdown menu may be placed next to the "Platform" dropdown menu.

Example: [x] in https://docs.rs/crate/dcpu/0.1.1

I've noticed that my README contains the following markdown:

* http://mearie.org/projects/esotope/bfc/
* http://calmerthanyouare.org/2015/01/07/optimizing-brainfuck.html
* [http://xn--2-umb.com/10/brainfuck-using-llvm](http://xn--2-umb.com/10/brainfuck-using-llvm)

On GitHub, this gives me three links, but on docs.rs, only the third bullet is rendered as an anchor tag.

Link to the readme: https://docs.rs/crate/bfc

"The requested crate does not exist" is the message if you try to load up docs for a crate that exists, in a version that does not. Could just use a small tweak in how it reports the error.

See https://docs.rs/crate/clippy/0.0.88 for an example, and compare to https://github.com/Manishearth/rust-clippy . In the latter, names like block_in_if_condition_expr show up correctly. docs.rs interprets the underscores as markup for italics, italicizing the in and the condition.

This likely represents a difference in markdown dialect from what most packages expect.

We have a project that follows along rust nightly in a very rolling fashion and sometimes we depend on rust nightly being a certain minimum version. As such, it would be nice if docs.rs could also always have the respective newest rust nightly.

Use case: if your library depends on some native library or otherwise does something funky during build, it won't be exposed on docs.rs.

The build could check for the presence of a docs feature in the Cargo.toml file, for example like this:

cargo read-manifest | rq 'select"$.features"|map(o)=>{_.keys(o)}|spread|some(x)=>{"docs"==x}'

(Shameless plug: rq)

Setting this docs feature would allow the library to "defuse" itself, by not running a build script or not trying to link a native library.

It would be nice if we could still replace the crates.io with crates.fyi to find the correct docs.rs page. E.g.
https://crates.fyi/crates/serde/ -> https://docs.rs/serde/.

Some crates have documentation and cratesfyi is building these crates fine. But cratesfyi unable to detect documentation of these crates. i.e:

• rustc-serialize

This issue needs to be solved before user interface (#12) going live.

Currently, docs.rs is looking for readme field in Cargo.toml to find out if a crate contains any readme. But looks like many crates have README's in their root directory but doesn't have any readme field in Cargo.toml.

docs.rs should automatically detect readmes instead of trusting crate owner.

For certain crates I'd like it if I could set the default target, so that when someone looks up a certain crate, they'd get the documentation I want them to get by default. Particularly useful for crates that only define things for certain targets, such as winapi.

Also useful would be a way to tell docs.rs which features to enable when building a crate. winapi 0.3 will have almost everything disabled by default, and then opting in with features, but that would end up with docs.rs generating useless documentation.

rs-tiled for example.

I couldn't figure anything out as to what does this actually do ?

For example, clicking links for traits in https://docs.rs/crate/eclectic/0.10.0 will result in The requested crate does not exist.

Because the Rust team is apparently incapable of hosting docs for more than one platform (rust-lang/rust#24658), it would be cool if docs.rs could host Rust docs for all the platforms.

It opens the same page in a new tab instead of just opening the drop down.

Would you be able to support generating documentation for the latest Git revision of crate?

This would be nice for many crates that are a work-in-progress, and as such don't have many of the latest features pushed up into a release on crates.io.