From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id uNhXEovwQ2WGNQAA9RJhRA:P1 (envelope-from ) for ; Thu, 02 Nov 2023 19:55:07 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id uNhXEovwQ2WGNQAA9RJhRA (envelope-from ) for ; Thu, 02 Nov 2023 19:55:07 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0E9CD274D6 for ; Thu, 2 Nov 2023 19:55:06 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=bayesians.ca header.s=protonmail2 header.b=Zn0ZY3yv; dmarc=pass (policy=quarantine) header.from=bayesians.ca; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1698951306; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=4H0HSUWBXa9TRpPpgZzcDA+ZVRKg6tPpcrVN0Jf5xNU=; b=jGb2rvQZewc5EN5eomG9nr4Tz8GJjOb0UEiDK/KkYHiWd+xar53soSFt2yOU6g1OifRqnV f25xpvPVqq4mWY4Q+rmaJ1WJ9rh8bYWT+OLAEI6xRcKE/voBtiX+hMM+hlvn5pn5yy08na 2zqM4BCfJGh1l7Ya2n8yu6O7KYERtV2ib9GMgK399CLpmcqr8W3zZ4Jngq+0y8DbqnpjtA Fqil8vRsGX75p8VYdfZep+79eVIg9uTMFYZ35DzEMpeVSqN6B9twxeB5rVmtzDBI0vOVZ0 9iJmfVCVz0X8dgb7Ul2WyOLTMUOAX4/yk6uB8bwZd7hUivtb9+BSefZXhy2VNg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=bayesians.ca header.s=protonmail2 header.b=Zn0ZY3yv; dmarc=pass (policy=quarantine) header.from=bayesians.ca; spf=pass (aspmx1.migadu.com: domain of "help-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="help-guix-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1698951306; a=rsa-sha256; cv=none; b=fC3Ye+x3MkBF5vlWRhugw6yFo6uoRvus+bBhNbmRkRLbuIX2yoQsOS0zVmenb3scjIQ7yw hmA2eDT7Q43wPeoly/B8ALemtYITBx8zQnvTj7PDI3SDeiaXdV0nT/rrQO0srtLyEOr+3V qTBvcFRucGNH5d3K2y+rWqPNOXdpFKtDNnd3722F+zPkJGH3DsMYjhRmZI7GoEeVYC0Yem Qm9tO5zGJLbGIuuH7zy4YyeexgWQc4JJHJ9lmL0lk6JxBdRuPCuX8lenRh6Jyza+wP6bWE 7Gw11fQLfWHnZOhg41nzrwe8dNS3paR/qf1wSvgB/DJi2SlFgRArESGVW9C5Jw== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qycpp-0007yk-39; Thu, 02 Nov 2023 14:54:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qycpn-0007yV-3N for help-guix@gnu.org; Thu, 02 Nov 2023 14:54:27 -0400 Received: from mail-4323.proton.ch ([185.70.43.23]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qycpk-0000ka-Cb for help-guix@gnu.org; Thu, 02 Nov 2023 14:54:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bayesians.ca; s=protonmail2; t=1698951260; x=1699210460; bh=4H0HSUWBXa9TRpPpgZzcDA+ZVRKg6tPpcrVN0Jf5xNU=; h=Date:To:From:Cc:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Zn0ZY3yvruNFoNEN4e7lt2IhGRJA6jQD3hG2bde2hwfUw7DeOzzUGAYcdw8AE5x1c WpgUQJe6bFryD5oJLFIcNECgzRCs+x25q9+r08Q2Qqfsd8/jSvFwuppR6ctP0+Nuek OSyPLQX5HE2wiarJOgZfMBdTzS7PJdCSKGXzIOhnxgPWFkkdSuempfTGBdnnIddSj6 6TMvMAPEx83WqWT4kCgp/6kxTKS8eGp/gwjBO4wGzQxm70KtmDkBBNAaCYuDOCeFFZ 38a1LcZak+hgqCNrtg0G0fRP4WJgM5cdA53Avi94xZa7R54IN9+MZvIzMz/sDzs/d0 KMegnMBXX/SgA== Date: Thu, 02 Nov 2023 18:54:14 +0000 To: Simon Tournier From: Suhail Cc: Suhail , Felix Lechner via , Julien Lepiller , Felix Lechner Subject: Re: Turning off tests leads to a different store item Message-ID: <87ttq4gf5c.fsf@> Feedback-ID: 38691229:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.23; envelope-from=suhail@bayesians.ca; helo=mail-4323.proton.ch X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-guix@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+larch=yhetil.org@gnu.org Sender: help-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -4.69 X-Spam-Score: -4.69 X-Migadu-Queue-Id: 0E9CD274D6 X-Migadu-Scanner: mx10.migadu.com X-TUID: OfGrvRbRenD7 Simon Tournier writes: > On Thu, 02 Nov 2023 at 15:25, Suhail wrote: > >> Yes, with the test derivation being something like a "fixed-output >> derivation". [[info:guix#Derivations][From the manual]]: > > No, it cannot be a =E2=80=9Cfixed-output=E2=80=9D derivation=E2=80=A6 > > =E2=80=A6because we cannot know in advance the expected content hash of t= he > tests output. Yes, hence the "something like". It's similar, but also different in important ways. > And from my understanding, one solution would be to have something as > below. One =E2=80=9Cobject=E2=80=9D for building and another =E2=80= =9Cobject=E2=80=9D for testing. > > ( Here, I am using the same object namely for the both; > just to make concrete the discussion. :-) ) > > The point is: we have two derivations; one for the build (without tests) > and another for the tests (without build). > > ... > > Somehow, we could have a =E2=80=9Cbuild=E2=80=9D build-system and a = =E2=80=9Ctest=E2=80=9D build-system. > And the =E2=80=9Cbuild object=E2=80=9D would be an inputs of the = =E2=80=9Ctest object=E2=80=9C. You are trying to reconcile our discussion with what you know about Guix internals which is both useful and necessary (eventually). However, since I have less knowledge of said internals at present, I am not able to meaningfully contribute to what the implementation may look like yet. What I can do, instead, is to articulate some invariances/properties that I believe are both desirable and reasonable (without considering how feasible or not they may be). First some notation. Let's say the "test metadata" captures the information of interest: were the tests run, and if so what was their outcome. A very simple (but sufficient for our purposes) datatype would be the union of null, #t and #f (where the test outcome is a boolean). It's possible that in practice, "test metadata" may have additional information (for instance a reference to the "build output" in the store), but we'll ignore that for now. I'll use "test output" to mean the combination of "test metadata" and "build output" where "build output" is also the input to the "thing that generates the 'test metadata'". So we have the property that the "test output" extends the "build output" by providing some companion information (i.e., the "test metadata"). The invariants of interest are about what things are considered equivalent. To my understanding this is captured in the Guix notion of what is and isn't considered a Substitute. 1. It should be possible to discard test metadata: We should be able to use "test output" as a substitute for "build output". I.e., a derivation that doesn't demand that we run the tests ought not to care whether or not we did. 2. "build output" can be used as a substitute for "test output" with null "test metadata". 3. It shouldn't be possible to vacuously manufacture test outcomes: "build output" cannot be used as a substitute for "test output" with either #t or #f "test metadata". If our hypothetical build system (say, ds-build-system) were to admit the above invariances, do you foresee some complications that may arise that need to be addressed? > Well, somehow perhaps some revamp of the record. Perhaps, but I am not quite there yet to consider how it might be implemented, because what "it" is is still not sufficiently clear to me. --=20 Suhail This email is not an offer capable of acceptance, does not evidence an intention to enter into an agreement, has no operative effect until a definitive agreement is signed in writing by both parties, and that no party should act in reliance on the email or any representations of the sender until a definitive agreement is signed in writing by both parties. This email may contain information that is privileged, confidential and/or exempt from disclosure. No waiver whatsoever is intended by sending this e-mail which is intended only for the named recipient(s). Unauthorized use, dissemination or copying is prohibited. If you receive this email in error, please notify the sender and destroy all copies of this email.