Closed ignatenkobrain closed 2 years ago
Those tests rely on submodule, so download it before (git submodule update —init
in the directory)
note that crates.io tarballs do not contain any git submodule information
Is there any way to specify it?
@NikVolf I believe that those files are excluded here: https://github.com/paritytech/parity-wasm/blob/master/Cargo.toml#L13
But if I remove it, every user will have to download the test suite, which is not at all needed
Hi @ignatenkobrain ! sorry for chiming in so late.
Cargo testing usually assumes that you're working with crate locally and crates.io packages don't always contain all necesarry files for testing.
I wonder why do you have such requirements?
We try to test all crates before we ship them to users when packaging in Fedora.
This works for most of the crates, but for those which do not, upstream usually add some flag which disables testing of data-dependent tests.
by doing this we catched a lot of different issues related to endianess and/or some specific versions of crates.
https://github.com/rust-lang-nursery/rust-bindgen/issues/1412 https://github.com/rustsim/nalgebra/issues/383 https://github.com/BurntSushi/rust-pcre2/issues/3 https://github.com/dtolnay/ryu/issues/2 https://github.com/sfackler/rust-openssl/issues/964 https://github.com/stratis-storage/devicemapper-rs/issues/343 https://github.com/mehcode/config-rs/issues/75 https://github.com/hyperium/mime/issues/85 https://github.com/sunng87/handlebars-rust/issues/219 https://github.com/serde-rs/test/issues/19 https://github.com/alexcrichton/filetime/issues/23 https://github.com/serde-rs/serde/issues/1230 https://github.com/servo/rust-cssparser/issues/214 https://github.com/tailhook/humantime/issues/2
Just some links for the references.
We try to test all crates before we ship them to users when packaging in Fedora.
Interesting! This is totally a legit case, but as I've said it's not officially supported... I would recommend to file an issue to cargo/crates.io repo to ask about officially supporting this use-case.
In the meantime, I think it should be possible to download the tests dynamically. Will look into that.
We stumbled over the same problem when packaging the crate for Debian. Unfortunately, adding a method to dynamically download the files also doesn't help, because in Debian all packages must be buildable without a network connection. In this case, I also think it's not worth distributing additional files of 30MB size, so I'll disable the tests for now. Even though running tests has surfaced several real issues in the past, similar to Fedora's experience.
Please either include them or somehow disable those tests by default. Thanks!