Re: Turning off tests leads to a different store item

[Suhail]

Simon Tournier <zimon.toutoune@gmail.com> writes:

> On Wed, 01 Nov 2023 at 17:52, Suhail <suhail@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.