Re: (not) testing Rust packages?!

[Andreas Rottmann]

John Soo <address@hidden> writes:

> Hey Andreas,
>
>> `cargo test` will always build the crate a second time, even if `cargo
>> build` already ran. This is due to the config attribute `test` being set
>> (similar a to C preprocessor #define), and thus the actual code being
>> compiled may be different.
>
> Just to make sure, does that mean we can safely run tests without
> having unwanted store outputs?
>
I'm a new to Guix, and am not sure what you mean by "safely" and
"unwanted store outputs". Running `cargo test` takes the crate source,
and the closure of any `dependencies` and `dev-dependencies`, and
produces no real artifacts that make sense to put in the store, as far
as I can see. The only noteworthy artifact is the stdout/stderr ouput
produced, as well as the exit status, but I guess that's not relevant to
the store.

> I can see that maybe the test compile step might not catch everything
> or compile the whole package, but wouldn't you say that some testing
> is better than none at all?
>
Having tests run would be great: it's a service to the Rust ecosystem,
and can also help catch issues in packaging, as was already pointed
out. How likely catching issues is depends on the testsuite quality of
the crate in question, but that's not at all an argument against running
tests, of course!

>> In addition, `cargo test` will bring in the
>> `dev-dependencies`, which can indeed be _much_ more massive than the
>> regular `dependencies`.
>
> Can you provide an example? [...]
>
This may have come across wrong: I just wanted to point out that it may
mean more packaging effort, but it seems Guix is in a good position here
already.