cbindgen icon indicating copy to clipboard operation
cbindgen copied to clipboard

docs.rs build failures with cbindgen in workspace crate

Open pkgw opened this issue 4 years ago • 4 comments
trafficstars

My package tectonic has a workspace dependency that uses cbindgen, and it won't build on docs.rs:

[INFO] [stderr]   thread 'main' panicked at 'Unable to generate bindings:
  CargoMetadata("/opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/tectonic_bridge_flate-0.1.1/Cargo.toml",
    Metadata(Output { status: ExitStatus(ExitStatus(25856)), stdout: "",
  stderr: "    Updating crates.io index\nwarning: spurious network error (2 tries remaining): 
    failed to resolve address for github.com: Temporary failure in name resolution; class=Net (12)

(log)

I think that what's going on here is that docs.rs builds packages without network access, and because this tectonic_bridge_flate sub-crate is part of a workspace, it's packaged without a Cargo.lock file. This means that cargo metadata has to hit the network in order to do its thing, but it errors out because of the docs.rs sandbox.

I see that cargo metadata has an --offline option, and perhaps the --no-deps argument also removes the need to pull the Crates.io index. Would there be a way to tune the cargo metadata operation to avoid the possible need to hit the network? This could potentially be selectively enabled for docs.rs only by checking the DOCS_RS environment variable.

Xref #560.

pkgw avatar Jun 15 '21 13:06 pkgw

Would there be a way to tune the cargo metadata operation to avoid the possible need to hit the network?

You can pass a metadata file to cbindgen already, does that not do the trick?

emilio avatar Jun 16 '21 08:06 emilio

@emilio I'm using cbindgen in my build.rs script — do you mean Builder::with_lockfile()? If my package is being built as a dependency of different crate, I don't think there's a way for the build.rs script to know where that lockfile is located? Note above that the build is happening in

$CARGO_HOME/registry/src/github.com-1ecc6299db9ec823/tectonic_bridge_flate-0.1.1/

and I don't think there's any way for the script to discover that the main source checkout, and therefore the Cargo.lock, happens to live in

/home/cratesfyi/workspace/builds/tectonic-0.6.1/

pkgw avatar Jun 16 '21 12:06 pkgw

Well, forcing offline operation seems to help (I did it at a higher level than cbindgen's cargo metadata invocation by setting CARGO_NET_OFFLINE=true), but unfortunately it's not enough. Now my docs.rs error is:

error: failed to write /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/tectonic_bridge_flate-0.1.4/Cargo.lock

Caused by:
  failed to open: /opt/rustwide/cargo-home/registry/src/github.com-1ecc6299db9ec823/tectonic_bridge_flate-0.1.4/Cargo.lock

Caused by:
  Read-only file system (os error 30)

So I need to avoid the cargo metadata call or somehow prevent it from trying to write out Cargo.lock (which is relevant to #560 as well).

pkgw avatar Jun 17 '21 04:06 pkgw

Would it work if cbindgen could pass --no-deps to cargo metadata? Based on my reading of the code and some quick testing, it looks like that option makes it so that cargo metadata doesn't try to create the lockfile.

edit: alas, it definitely will not. May need to put in a PR to Cargo ...

pkgw avatar Jun 17 '21 04:06 pkgw