Port books to mdbook #39633
Port books to mdbook #39633
Conversation
steveklabnik
changed the title
|
Oh, and pour one out for |
|
Looking good! I take it that the Also, I think that you'll need to re-run |
Ah ha! I always forget about submodules; totally.
yes, that shouldn't be too bad. It's a tiny file. |
|
Ok in that case let's scratch the submodule idea and instead just depend on it as a library, vendor a small bit of the book logic, and then we can rely on cargo-vendor to pull in the vendor'd deps |
|
@alexcrichton I guess I'll call this wrapper........... rustbook. IT LIVES |
|
@alexcrichton I think I did this correctly... |
|
Are all these fingerprint files intentional? I don't really know what they are, so maybe they are intentional? |
|
@frewsxcv not sure, i just ran |
|
Hrm, looks like maybe the vendoring didn't work? https://travis-ci.org/rust-lang/rust/jobs/199465089#L371 |
|
I'm not sure, but I feel like this file shouldn't be there: https://github.com/steveklabnik/rust/blob/041312e1909be2954852317339629715d314e045/src/target/release/.fingerprint/kernel32-sys-4995bb2d2dfb906c/dep-build-script-build_script_build-4995bb2d2dfb906c maybe some bug in cargo vendor? |
|
@alexcrichton i added a |
|
It is unclear to me why this works for me locally but fails on travis :( |
|
@est31 points out to me on IRC that the bots are using |
|
|
mdBook is designed to be able to be used as a library, but I think you are the first ones actually using it like that |
|
I am extremely confused. yet the update doesn't show up here. hmmmmmmmmmmmmmmmmmmm |
steveklabnik
force-pushed
the
vendor-mdbook
branch
from
bb66fa9
to
3812b66
Compare
|
It looks like github is having some issues; I assume this PR will be updated soon, then. |
|
Okay, I don't know why the bot is failing here; I can run (It fails with license issues, but it doesn't fail like it does on travis) |
|
Here is the summary of license issues: So, that's
All of the Unlicense projects are dual with MIT, so the real issue is |
mdBook is also licensed under the MPL 2.0, is that a problem? |
|
@azerupi interesting, wonder why it wasn't caught by the lint. We're going to discuss it at the core team meeting today; it's not inherently a problem, but right now, everything in the repo is licensed identically. Moving away from that would be a big change, possibly. |
|
Updating myself: it appears that I did not run It's not clear why, with the vendor, it says that it's looking at crates.io to get the source and can't find it. |
|
@azerupi expect a post on internals sometime in the near-ish future; we're going to ask everyone what they think |
|
Internals post is here: https://internals.rust-lang.org/t/licenses-of-vendored-tools-in-the-rust-repo/4758 |
|
|
Automate vendoring by invoking cargo-vendor when building src dist tarballs. This avoids #39633 bringing the `src/vendor` checked into git by #37524, past 200,000 lines of code. I believe the strategy of having rustbuild run `cargo vendor` during the `dist src` step is sound. However, the only way to be sure `cargo-vendor` exists is to run `cargo install --force cargo-vendor`, which will recompile it every time (not passing `--force` means you can't tell between "already exists" and "build error"). ~~This is quite suboptimal and I'd like to somehow do it in each `Dockerfile` that would need it.~~ * [ ] Cache `CARGO_HOME` (i.e. `~/.cargo`) between CI runs * `bin/cargo-vendor` and the actual caches are the relevant bits * [x] Do not build `cargo-vendor` all the time * ~~Maybe detect `~/.cargo/bin/cargo-vendor` already exists?~~ * ~~Could also try to build it in a `Dockerfile` but do we have `cargo`/`rustc` there?~~ * Final solution: check `cargo install --list` for a line starting with `cargo-vendor ` cc @rust-lang/tools
Automate vendoring by invoking cargo-vendor when building src dist tarballs. This avoids #39633 bringing the `src/vendor` checked into git by #37524, past 200,000 lines of code. I believe the strategy of having rustbuild run `cargo vendor` during the `dist src` step is sound. However, the only way to be sure `cargo-vendor` exists is to run `cargo install --force cargo-vendor`, which will recompile it every time (not passing `--force` means you can't tell between "already exists" and "build error"). ~~This is quite suboptimal and I'd like to somehow do it in each `Dockerfile` that would need it.~~ * [ ] Cache `CARGO_HOME` (i.e. `~/.cargo`) between CI runs * `bin/cargo-vendor` and the actual caches are the relevant bits * [x] Do not build `cargo-vendor` all the time * ~~Maybe detect `~/.cargo/bin/cargo-vendor` already exists?~~ * ~~Could also try to build it in a `Dockerfile` but do we have `cargo`/`rustc` there?~~ * Final solution: check `cargo install --list` for a line starting with `cargo-vendor ` cc @rust-lang/tools
Automate vendoring by invoking cargo-vendor when building src dist tarballs. This avoids #39633 bringing the `src/vendor` checked into git by #37524, past 200,000 lines of code. I believe the strategy of having rustbuild run `cargo vendor` during the `dist src` step is sound. However, the only way to be sure `cargo-vendor` exists is to run `cargo install --force cargo-vendor`, which will recompile it every time (not passing `--force` means you can't tell between "already exists" and "build error"). ~~This is quite suboptimal and I'd like to somehow do it in each `Dockerfile` that would need it.~~ * [ ] Cache `CARGO_HOME` (i.e. `~/.cargo`) between CI runs * `bin/cargo-vendor` and the actual caches are the relevant bits * [x] Do not build `cargo-vendor` all the time * ~~Maybe detect `~/.cargo/bin/cargo-vendor` already exists?~~ * ~~Could also try to build it in a `Dockerfile` but do we have `cargo`/`rustc` there?~~ * Final solution: check `cargo install --list` for a line starting with `cargo-vendor ` cc @rust-lang/tools
Automate vendoring by invoking cargo-vendor when building src dist tarballs. This avoids #39633 bringing the `src/vendor` checked into git by #37524, past 200,000 lines of code. I believe the strategy of having rustbuild run `cargo vendor` during the `dist src` step is sound. However, the only way to be sure `cargo-vendor` exists is to run `cargo install --force cargo-vendor`, which will recompile it every time (not passing `--force` means you can't tell between "already exists" and "build error"). ~~This is quite suboptimal and I'd like to somehow do it in each `Dockerfile` that would need it.~~ * [ ] Cache `CARGO_HOME` (i.e. `~/.cargo`) between CI runs * `bin/cargo-vendor` and the actual caches are the relevant bits * [x] Do not build `cargo-vendor` all the time * ~~Maybe detect `~/.cargo/bin/cargo-vendor` already exists?~~ * ~~Could also try to build it in a `Dockerfile` but do we have `cargo`/`rustc` there?~~ * Final solution: check `cargo install --list` for a line starting with `cargo-vendor ` cc @rust-lang/tools
|
|
|
@bors: p=1 I'm giving this a priority because there are a few PRs to the book that will need to be rebased after this PR, and this PR has already been sitting in the queue for three days. |
|
|
Port books to mdbook Part of #39588 blocked on #39431 As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful. r? @alexcrichton @brson /cc @azerupi
|
|
|
@bors: retry |
|
|
Port books to mdbook Part of #39588 blocked on #39431 As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful. r? @alexcrichton @brson /cc @azerupi
|
|
|
… On Tue, Feb 14, 2017 at 4:46 PM, bors ***@***.***> wrote:
|
|
|
Port books to mdbook Part of #39588 blocked on #39431 As a first step towards the bookshelf, we ~vendor mdbook in-tree and~ port our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful. r? @alexcrichton @brson /cc @azerupi
|
|
|
could we perhaps switch back to the rustbook color scheme? |
Part of #39588
blocked on #39431
As a first step towards the bookshelf, we
vendor mdbook in-tree andport our books to it. Eventually, both of these books will be moved out-of-tree, but the nightly book will rely on doing the same thing. As such, this intermediate step is useful.r? @alexcrichton @brson
/cc @azerupi