Simon Tournier <zimon.touto...@gmail.com> writes: > On Wed, 01 Nov 2023 at 17:52, Suhail <suh...@bayesians.ca> wrote: > >> If not, why should skipping the tests result in a different >> derivation tree? > > The store path is different because it hashes all the inputs, included > the builder script; from my understanding.
It certainly seems to be the case. Would you know the specific place(s) in the source code (in addition to guix/derivations.scm and guix/store.scm) that would be relevant for this discussion? On a related note, is Dolstra's phd thesis relevant for these aspects, or do you know if Guix diverges from Nix in some areas? > Well, from my understanding, get the same the store path for the same > package built with or without its tests ... would mean to have a > derivation for building and another derivation – referring to the > former – for testing. Yes, with the test derivation being something like a "fixed-output derivation". [[info:guix#Derivations][From the manual]]: #+begin_quote Operations such as file downloads and version-control checkouts for which the expected content hash is known in advance are modeled as fixed-output derivations. Unlike regular derivations, the outputs of a fixed-output derivation are independent of its inputs—e.g., a source code download produces the same result regardless of the download method and tools being used. #+end_quote The hypothetical test derivation leaves the build artifact unchanged, but does communicate some "side" information. It's like a fixed-output derivation carrying some metadata (further elaboration below). > Well, taking this direction, one could imagine a derivation for each > phases; somehow extend to all phases what it is already done for > fetching source, build and grafts (guix build --source && guix build > --no-grafts && guix build). Perhaps not all. The thing that sets the "check" phase (#:tests?) apart from the rest is that it's an identity transform with a side-effect. i.e., it simply reports on the state of its input (i.e., the build artifact) leaving the build artifact unchanged. The only other phase in the gnu-build-system that is similar to the "check phase" is the "validate-runpath phase". An alternative (possibly future) version of Guix might allow us to delay the interpretation/meaning associated with the following cases: - whether or not the tests were run, and - whether or not the tests, if run, passed To be able to do so, we need the "check derivation" be able to communicate two things (downstream): a summary of the test phase (could simply be a 3-valued datatype, like a 'Maybe Bool' in Haskell, but could also be something more elaborate), and the input build artifact (which remains unchanged). Similarly for the "validate-runpath derivation". I do not know what the best way to communicate the "side-effect information" (did the tests run and if so what was the conclusion) would be. Specifically, should the output of "check derivation" (similarly for "validate-runpath derivation") include the unchanged build artifact or not? Btw, is this still the appropriate mailing list (and more generally, forum) for this discussion? -- 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.