Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optionally document dev-dependencies #3475

Open
masklinn opened this issue Dec 30, 2016 · 9 comments
Open

Optionally document dev-dependencies #3475

masklinn opened this issue Dec 30, 2016 · 9 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-doc S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@masklinn
Copy link

Currently cargo doc will build documentation for the crate and its dependencies, which is useful as (outside of the core Rust distribution) you get a one stop shop of documentation while working on a crate, however as far as I could see "dev-dependencies" can't be included in that.

This is inconvenient for test-support libraries and for complex "examples" e.g. in a library crate you want a binary which depends on docopt/clap or ncurses or winapi or the Ruby C API or some other large dependency which is completely unnecessary for the core library, but you don't want to fork it to a separate crate, so you make it an example and use dev dependencies, however you've now lost offline access to the "large dependency"'s documentation.

@alexcrichton
Copy link
Member

Sounds like a good idea to me! I could imagine something like cargo doc --dev or something like that for this.

@yaahc
Copy link
Member

yaahc commented Jun 27, 2019

I'd like to implement this feature

@skull-squadron
Copy link

I was just looking for this. Awesome progress, keep going! 🍻

@yaahc
Copy link
Member

yaahc commented Aug 13, 2019

It will be done soon! Just been focusing on cargo fix --clippy for the time being, almost done with that though I think.

@xoac
Copy link

xoac commented Aug 31, 2020

It's worth to mention that when you run cargo test your dev-dependencies crates are used in checking your docs example code. But when you build documentation (cargo +nightly doc) these crates are ignored in links.

warning: unresolved link to `static_bytes::SafeBytesSlice`
   --> src/mac/frame/mod.rs:279:29
    |
279 |     /// [`SafeBytesSlice`]: static_bytes::SafeBytesSlice
    |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unresolved link
    |
    = note: `#[warn(broken_intra_doc_links)]` on by default
    = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

warning: 1 warning emitted

Version:

cargo +nightly version
cargo 1.47.0-nightly (51b66125b 2020-08-19)

@nathan-at-least
Copy link

Any progress here? What are some next steps? Any way I can help?

I'd really appreciate this feature because I frequently do "offline" development where I run cargo doc, then go offline and having the dev dependency docs is often important since I try to spend a lot of dev effort on improving tests.

@nextuponstream
Copy link

Current workaround is to add your dev-dependencies under [dependencies] in Cargo.toml, run cargo doc, then comment added dependencies. As long as you don't clean target/doc, they will still be there even if your run cargo doc again.

@notgull
Copy link

notgull commented Jul 26, 2022

Is there any progress on this issue?

@epage
Copy link
Contributor

epage commented Sep 30, 2023

#11105 gets in the way of doing this manually.

@epage epage added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. labels Oct 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-doc S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
9 participants