From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Soo Subject: Re: (not) testing Rust packages?! Date: Sat, 25 Jan 2020 08:46:48 -0800 Message-ID: References: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56701) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ivOaD-0001Wo-4S for guix-devel@gnu.org; Sat, 25 Jan 2020 11:46:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ivOaB-0000fS-Ra for guix-devel@gnu.org; Sat, 25 Jan 2020 11:46:52 -0500 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]:32872) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ivOaB-0000cQ-F9 for guix-devel@gnu.org; Sat, 25 Jan 2020 11:46:51 -0500 Received: by mail-ot1-x32e.google.com with SMTP id b18so4614286otp.0 for ; Sat, 25 Jan 2020 08:46:51 -0800 (PST) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Martin Becze Cc: guix-devel@gnu.org Hi Hartmut and Martin, I think it makes sense to run tests now. > Part of the reason is that bringing tests for a given library can bring in= a massive amount of dependencies. I think that we are getting close to having complete dependencies for most r= ust packages we have and most are declared in the package definition.=20 Furthermore since most rust libraries we have are not executables, we could s= till skip the build and run the tests I think. Aren=E2=80=99t the two phases= completely separate for cargo? Other downsides I see for not skipping the build are really increasing the s= tore size. Would skipping builds but still running tests increase the store= size at all? I like the idea of having tests, too. Plus I=E2=80=99d like to see the carg= o build system come closer to the standard package definition. John=