Closed jayvdb closed 3 months ago
I did a little digging into why I have rustix-0.37.27
in my dep tree, and it comes in because async-std hasnt had a release in two years ( https://github.com/async-rs/async-std/issues/1081 ) .
Is there any way to skip cargo-acl analysis of this crate version?
I had a quick try to reproduce by creating a simple crate that depends on rustix
. So far I haven't been able to. Based on the errors, I'd guess that maybe rustix's build script is getting confused and activating configurations that are only supposed to be used on nightly. That's just a guess though.
Some bits of information that might be useful for me to help reproduce this:
Cargo.toml
that pulls in rustix
. In particular any features or other settings.rust-toolchain.toml
in your project etcIs there any way to skip cargo-acl analysis of this crate version?
Unfortunately there isn't. Cackle runs cargo build
on your project and instruments the build so as to analyse each build artifact. So skipping things isn't really an option, because then the thing wouldn't be built and the rest of the build would fail.
Ah, so you're not depending on rustix directly. I'll have a look and see if I can reproduce via a dependency on async-std
.
Good news. I managed to reproduce the problem :)
The top level source of this problem is httpmock
rustix v0.37.27
└── async-io v1.13.0
├── async-process v1.8.1
│ └── async-std v1.12.0
│ ├── async-object-pool v0.1.4
│ │ └── httpmock
...
│ └── httpmock v0.7.0 (*)
└── async-std v1.12.0 (*)
I have other rustix in my Cargo.lock , and cargo-acl seems to able to process them.
Im using rustup ; have no rust-toolchain.toml
, Linux, etc
It looks like it only reproduces if I don't enable sandboxing of build scripts. i.e. this triggers the bug:
[sandbox]
kind = "Disabled"
This builds fine:
[sandbox]
kind = "Bubblewrap"
So if it's an option to install bubblewrap
, then that would at least give you a workaround until I can figure out and fix the bug. Sandboxing of build scripts is nice to have anyway :)
Confirming that workaround. Thanks.
My project builds correctly, and has several versions of rustix in our Cargo.lock, but with
cargo-acl
& using rust 1.80 it fails atrustix-0.37.27
with:The code in question is at https://github.com/bytecodealliance/rustix/blob/v0.37.27/src/lib.rs#L101
During cargo-acl, I get the following problems before it crashes with the above
My cackle.toml already contains the following, so I assume that cargo-acl has already gotten one version of
rustix
working on my project.My cackle.toml
common
secton only containsversion = 2