John Soo <js...@asu.edu> 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.