Code Monkey home page Code Monkey logo

docs.rs's Introduction

Docs.rs

Build Status License

Docs.rs (formerly cratesfyi) is an open source project to host documentation of crates for the Rust Programming Language.

Docs.rs automatically builds crates' documentation released on crates.io using the nightly release of the Rust compiler.

This readme is for developing docs.rs. See the about page for user-facing documentation.

How the documentation is generated

docs.rs uses rustdoc to generate the documentation for every crate release on crates.io. You can read the the rustdoc book for more details.

Changing the build environment

To make a change to the build environment and test that it works on docs.rs, see the wiki.

Development

The recommended way to develop docs.rs is a combination of cargo run for the main binary and docker-compose for the external services. This gives you reasonable incremental build times without having to add new users and packages to your host machine.

Git Hooks

For ease of use, git_hooks directory contains useful git hooks to make your development easier.

# Unix
cd .git/hooks && ln -s ../../.git_hooks/* . && cd ../..
# Powershell
cd .git/hooks && New-Item -Path ../../.git_hooks/* -ItemType SymbolicLink -Value . && cd ../..

Dependencies

Docs.rs requires at least the following native C dependencies.

  • gcc
  • g++
  • pkg-config
  • git
  • make
  • cmake
  • zlib
  • openssl (with dev pkgs) -- Ubuntu example sudo apt install libssl-dev

There may be other dependencies that have not been documented.

Getting started

Make sure you have docker-compose and are able to download ~10GB data on the first run. Also ensure that docker is installed and the service is running.

git clone https://github.com/rust-lang/docs.rs.git docs.rs
cd docs.rs
git submodule update --init
# Configure the default settings for external services
cp .env.sample .env
# Create the DOCSRS_PREFIX directory
mkdir -p ignored/cratesfyi-prefix/crates.io-index
# Builds the docs.rs binary
SQLX_OFFLINE=1 cargo build
# Start the external services.
# It may be `docker compose` in newer versions
docker-compose up -d db s3
# anything that doesn't run via docker-compose needs the settings defined in
# .env. Either via `. ./.env` as below, or via any dotenv shell integration.
. ./.env
# allow downloads from the s3 container to support the /crate/.../download endpoint
mcli policy set download docsrs/rust-docs-rs
# Setup the database you just created
cargo run -- database migrate
# Update the currently used toolchain to the latest nightly
# This also sets up the docs.rs build environment.
# This will take a while the first time but will be cached afterwards.
cargo run -- build update-toolchain
# Build a sample crate to make sure it works
cargo run -- build crate regex 1.3.1
# This starts the web server but does not build any crates.
# It does not automatically run the migrations, so you need to do that manually (see above).
cargo run -- start-web-server
# If you want the server to automatically restart when code or templates change
# you can use `cargo-watch`:
cargo watch -x "run -- start-web-server"

If you need to store big files in the repository's directory it's recommended to put them in the ignored/ subdirectory, which is ignored both by git and Docker.

Running the database and S3 server outside of docker-compose is possible, but not recommended or supported. Note that you will need docker installed no matter what, since it's used for Rustwide sandboxing.

Running tests

cargo test

To run GUI tests:

./dockerfiles/run-gui-tests.sh

They use the browser-ui-test framework. You can take a look at its documentation here.

Pure docker-compose

If you have trouble with the above commands, consider using docker-compose up --build, which uses docker-compose for the web server as well. This will not cache dependencies - in particular, you'll have to rebuild all 400 whenever the lockfile changes - but makes sure that you're in a known environment so you should have fewer problems getting started.

You can also use the web container to run builds on systems which don't support running builds directly (mostly on Mac OS or Windows):

# run a build for a single crate
docker-compose run web build crate regex 1.3.1
# or build essential files
docker-compose run web build add-essential-files
# rebuild the web container when you changed code.
docker-compose build web

Note that running tests is not supported when using pure docker-compose.

Please file bugs for any trouble you have running docs.rs!

Docker-Compose

The services started by Docker-Compose are defined in docker-compose.yml. Three services are defined:

name access credentials description
web http://localhost:3000 N/A A container running the docs.rs binary
db postgresql://cratesfyi:password@localhost:15432 - Postgres database used by web
s3 http://localhost:9000 cratesfyi - secret_key MinIO (simulates AWS S3) used by web

Rebuilding Containers

To rebuild the site, run docker-compose build. Note that docker-compose caches the build even if you change the source code, so this will be necessary anytime you make changes.

If you want to completely clean up the database, don't forget to remove the volumes too:

$ docker-compose down --volumes

FAQ

I see the error standard_init_linux.go:211: exec user process caused "no such file or directory" when I use docker-compose.

You probably have CRLF line endings. This causes the hashbang in the docker-entrypoint to be /bin/sh\r instead of /bin/sh. This is probably because you have git.autocrlf set to true, set it to input instead.

I see the error /opt/rustwide/cargo-home/bin/cargo: cannot execute binary file: Exec format error when running builds.

You are most likely not on a Linux platform. Running builds directly is only supported on x86_64-unknown-linux-gnu. On other platforms you can use the docker-compose run web build [...] workaround described above.

See rustwide#41 for more details about supporting more platforms directly.

All tests are failing or timing out

Our test setup needs a certain about of file descriptors.

At least 4096 should be enough, you can set it via:

$ ulimit -n 4096

CLI

See cargo run -- --help for a full list of commands.

Starting the web server

# This command will start web interface of docs.rs on http://localhost:3000
cargo run -- start-web-server

build subcommand

# Builds <CRATE_NAME> <CRATE_VERSION> and adds it into database
# This is the main command to build and add a documentation into docs.rs.
# For example, `docker-compose run web build crate regex 1.1.6`
cargo run -- build crate <CRATE_NAME> <CRATE_VERSION>

# alternatively, via the web container
docker-compose run web build crate <CRATE_NAME> <CRATE_VERSION>

# Builds every crate on crates.io and adds them into database
# (beware: this may take months to finish)
cargo run -- build world

# Builds a local package you have at <SOURCE> and adds it to the database.
# The package does not have to be on crates.io.
# The package must be on the local filesystem, git urls are not allowed.
# Usually this command can be applied directly to a crate root
# In certain scenarios it might be necessary to first package the respective
# crate by using the `cargo package` command.
# See also /docs/build-workspaces.md
cargo run -- build crate --local /path/to/source

database subcommand

# Adds a directory into database to serve with `staticfile` crate.
cargo run -- database add-directory <DIRECTORY> [PREFIX]

# Updates repository stats for crates.
# You need to set the DOCSRS_GITHUB_ACCESSTOKEN
# environment variable in order to run this command.
# Set DOCSRS_GITLAB_ACCESSTOKEN to raise the rate limit for GitLab repositories,
# or leave it blank to fetch repositories at a slower rate.
cargo run -- database update-repository-fields

If you want to explore or edit database manually, you can connect to the database with the psql command.

. ./.env
psql $DOCSRS_DATABASE_URL

The database contains a blacklist of crates that should not be built.

# List the crates on the blacklist
cargo run -- database blacklist list

# Adds <CRATE_NAME> to the blacklist
cargo run -- database blacklist add <CRATE_NAME>

# Removes <CRATE_NAME> from the blacklist
cargo run -- database blacklist remove <CRATE_NAME>

If you want to revert to a precise migration, you can run:

cargo run -- database migrate <migration number>

daemon subcommand

# Run a persistent daemon which queues builds and starts a web server.
cargo run -- daemon --registry-watcher=disabled
# Add crates to the queue
cargo run -- queue add <CRATE> <VERSION>

Updating vendored sources

The instructions & links for updating Font Awesome can be found on their website. Similarly, Pure-CSS also explains on theirs.

When updating Font Awesome, make sure to change $fa-font-path in scss/_variables.scss (it should be at the top of the file) to ../-/static. This will point font awesome at the correct path from which to request font and icon resources.

Contact

Docs.rs is run and maintained by the docs.rs team. You can find us in #t-docs-rs on zulip

docs.rs's People

Contributors

alanhdu avatar almusil avatar byron avatar camelid avatar cynecx avatar dependabot[bot] avatar dtolnay avatar emilgardis avatar folyd avatar guillaumegomez avatar jonas-schievink avatar jonhoo avatar jsha avatar jyn514 avatar kixiron avatar l4l avatar linyihai avatar mark-simulacrum avatar nemo157 avatar notriddle avatar onur avatar pickfire avatar pietroalbini avatar quietmisdreavus avatar reese avatar robinhundt avatar syphar avatar tesuji avatar urgau avatar zexbe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

docs.rs's Issues

github (repository) links are hard to find

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!)

Dual path/crates.io dependencies cause failures.

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" } })

Update rust nightly

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.

Markdown Reference Links are Broken

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.

Link to crates.io for each crate

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?

Cross-crate source links don't resolve.

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

README detection

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.

Crate failed to build

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.

Invalid version requirement

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.

Can you update the rust nightly every night?

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.

Linkify bare URLs

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

Sort crate version numerically

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                   -

Set a specific feature during doc generation

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.

Support Generating Docs for the Latest Git Revision

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.

Add gitlab statistics similar to github

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

Show owners, not only authors

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.

Platform switch should attempt to preserve current module

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.

What should happen if crate name conflicting with internal link like https://docs.rs/releases and https://docs.rs/about

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.

Set default target for certain crates, also features

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.

Update rustc version.

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

Purge badges cached by GitHub's proxy

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}

crates.fyi links don't work anymore

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/.

Idea: quick dropdown menu to switch between versions

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.

Idea: Show small badge to jump to newest version

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.