Re: [RFC]: Skipping rust crate tests by default

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

> Currently for for rust crates we build the crates, run the tests, and
> then in %output we only have the license files and a repackaged version
> of the source.
>
> The build system goes:
> unpack source
> unpack crates
> patch shebangs
> patch checksums of the crates
> 'build
> 'package
> 'check
> 'install
>
> 'install is clear, it does whatever the install command is.
>
> 'package repacks the source crate, after we've done any changes to it in
> the snippet and later if we've gone and patched paths to binaries or
> libraries. In theory this is useful with using these crates in a
> GUIX_ENVIRONMENT
>
> 'check runs the test suite, which fairly often seems to need some
> massaging to skip the odd test which fails or to try to skip the doc
> tests, which fail far too often.

Why do the doc tests often fail?  Is something wrong on our side?  As
rust aims to be fully deterministic, unless we stray too far away from
the specified input versions, it seems these failures should not happen
or be reported upstream.

> 'build sounds like it just builds the package. The first thing it does
> it makes sure that all the necessary crates are included in the build
> environment.
>
> IMO the 'build phase is the most important one, it's the one that lets
> us know if all the cargo-inputs and cargo-development-inputs are
> correct. We don't care if rust-rand-0.6 or rust-nb-connect-1 builds, we
> only care that it has the correct inputs so that when we pull it in for
> an actual binary or library everything builds correctly.
>
> I propose changing the cargo-build-system to have '#:tests? #f' by
> default and then enable them for packages which have a "clear output".
> It will keep the benefits of knowing we have the correct inputs without
> worrying about test errors we don't care about. If it fails to build
> during its own 'build phase that's actually worth looking into. It will
> also cut down the amount of time the CI spends building unneeded rust
> crates, and lets us see which ones are actually broken.

It seems useful to me to have some assurance that each crate packaged in
Guix passes its test suite, so I'm reticent to have a #:tests? #f by
default, while I sympathize with the work that is it given the sheer
amount of Rust crates.

-- 
Thanks,
Maxim