unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: guix-devel@gnu.org
Cc: "Ludovic Courtès" <ludo@gnu.org>
Subject: Re: [RFC]: Skipping rust crate tests by default
Date: Wed, 18 Oct 2023 14:46:57 -0400	[thread overview]
Message-ID: <87sf67sr8e.fsf@gmail.com> (raw)
In-Reply-To: <ZS-ZIOaPp1xiBkT-@pbp> (Efraim Flashner's message of "Wed, 18 Oct 2023 11:36:48 +0300")

Hi Efraim,

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

[...]

>> This sounds good except I don't understand how disabling the tests by
>> default help to "make sure that the packages have the correct inputs" ?
>
> When the tests are disabled, if a package shows red on the CI it means
> that either:
> A) there was a bundled shared/static library in the sources which need
> to be removed
> B) The inputs weren't correct and need to be fixed.
> What we're skipping is C) the test suite failed.
>
> When we get to the 'build phase of the cargo-build-system, cargo first
> checks that it has all of the crates listed in the Cargo.toml file, and
> that all of those crates have all of their (cargo-input) dependencies,
> and so on. If any of them are missing then the build will fail. This is
> also why we need to set #:skip-build? #t when we don't include the
> desired cargo-development-inputs.
>
> The change is mainly a quality of life improvement; it decreases the
> time that guix people and CI spend building these crates, and it makes
> it easier to see which, if any, rust packages need to be checked for
> brokenness (with the assumption that a broken or bit-rotted test suite
> isn't a problem).

I understand that maintaining the large fleet of cargo crates packaged
in Guix is a lot of work, but I think we can try some things before
#:tests? #f; I gathered some idea below.

> My premise is that the test suite of crates doesn't necessarily pass
> when built and run with a newer rust and that we shouldn't be concerned
> about it.
>
>> You've explained the rationale here:
>> <https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00182.html>,
>> saying we sometimes use a newer Rust than the package tests are
>> expecting; how does it work in the Rust world?  Don't they always build
>> even older versions against the most recent compiler?  What about the
>> test suites then?  Are these not typically run by users/distributions?
>
> In general, since rust expects all of the crates to be in source form,
> the tests are only run by developers when the crate is being developed.
> If someone comes along and uses that crate as a dependency for their
> project then they don't run the tests. If they continue using that crate
> (at that version) for several years then the developer using that older
> crate as a dependency still only compiles the part of the crate they
> need for their project and they only run the tests for their project,
> not for the crates which they've used as dependencies.

OK.

> As far as distributions, I can talk for Debian that they only provide
> the crates as -dev packages, that is, as the source crates. They make
> sure that they compile (and probably that they pass the test suite) at
> the time that they are packaged, but no one is distributing pre-compiled
> crates as packages to be used as inputs for further packages.

I believe that's the more useful comparison for our discussion; I gather
that even -dev crates are built and have their test suite run when
submitted, but since source packages are not rebuilt (they are a static
archive, right?) then there's no checking that the test suite continues
working in time.

>
> For an example of a failing doc-test, from the rust-nalgebra-0.21 crate:
>
>
>    Doc-tests nalgebra
> error: unnecessary parentheses around index expression
>   --> /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:45:47
>    |
> 45 |                 conv[i] += self[u_i] * kernel[(i - u_i)];
>    |                                               ^       ^
>    |
> note: the lint level is defined here
>   --> /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/lib.rs:78:9
>    |
> 78 | #![deny(unused_parens)]
>    |         ^^^^^^^^^^^^^
> help: remove these parentheses
>    |
> 45 -                 conv[i] += self[u_i] * kernel[(i - u_i)];
> 45 +                 conv[i] += self[u_i] * kernel[i - u_i];
>    |
>
> error: unnecessary parentheses around index expression
>   --> /tmp/guix-build-rust-nalgebra-0.21.1.drv-0/nalgebra-0.21.1/src/linalg/convolution.rs:49:53
>    |
> 49 |                         conv[i] += self[u] * kernel[(i - u)];
>    |                                                     ^     ^
>    |
> help: remove these parentheses
>    |
> 49 -                         conv[i] += self[u] * kernel[(i - u)];
> 49 +                         conv[i] += self[u] * kernel[i - u];
>    |
>
> error: aborting due to 2 previous errors
>
> error: doctest failed, to rerun pass `--doc`
>
>
> crates.io lists this version as being released more than 3 years ago and
> targeting the 2018 edition of rust. When built with our current
> rust-1.68.2 the doc test passes but not with 1.70.0.  The current
> upstream version of nalgebra is 0.32.3, so it's unlikely that they'd
> release a new version with the doc tests fixed, but I haven't contacted
> them about it.

OK.  Asking in ##rust on libera chat (unofficial channel), I got as suggestion
to call 'carge test' with the '--cap-lints=allow' option documented
here [0], which should effectively disable just the lint checks, which
is better than disabling the full test suite.

[0]  https://doc.rust-lang.org/rustc/lints/levels.html

>> For one thing the 'guix lint' command would need to be told that
>> cargo-build-system has #:tests? set to #f by default to not warn without
>> reasons that '#:tests? #t' is unnecessary.
>
> Instead of #:tests? #t I used (not (%current-target-system)), but I
> hadn't tested it with guix lint to see if that would need to be changed.

That means tests are disabled only when cross-compiling, right?  Do we
support cross-compiling rust crates?

-- 
Thanks,
Maxim


  reply	other threads:[~2023-10-18 18:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-05 12:52 [RFC]: Skipping rust crate tests by default Efraim Flashner
2023-10-05 16:38 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-10-15 10:18   ` Josselin Poiret
2023-10-16 15:47 ` Maxim Cournoyer
2023-10-17  7:46   ` Efraim Flashner
2023-10-18  8:36 ` Efraim Flashner
2023-10-18 18:46   ` Maxim Cournoyer [this message]
2023-10-23 10:04     ` Efraim Flashner
2023-10-23 15:51       ` Maxim Cournoyer
  -- strict thread matches above, loose matches on Subject: below --
2023-10-05 18:13 Nathan Dehnel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sf67sr8e.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).