Re: Turning off tests leads to a different store item

[Suhail <suhail@bayesians.ca>]

Greg Hogan <code@greghogan.com> writes:

> On Thu, Nov 2, 2023 at 11:26 AM Suhail <suhail@bayesians.ca> wrote:
>> 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".
>
> Should this say "without side-effects"?

No, I meant "with side-effect", but we have a notational
difference. What is termed side-effect is context dependent, so I'll fix
my terminology and make clearer what I meant. To me, the "check" phase
is something that reports on the state of its input. Said report (i.e.,
whether or not the check phase was run, and if run what its output was)
is what I was using the term "side-effect" for. Perhaps "test state
metadata" would be a better term.

> How does one guarantee that the test phase is free of side-effects?

Translation to remove ambiguity of the term "side-effect": How does one
guarantee that the test phase doesn't modify its input build artifact?

This could be enforced using an overlay layer as you suggest, but we
could also take a different approach. It would be sufficient to be able
to distinguish well-behaved tests (those that don't alter the input
build-artifact) from those that aren't (i.e., those that do alter the
input build-artifact).

> Alternatively, could we make it easier to record a timestamp in the
> manifest for Guix to use as the build clock time?

While that would address the original issue that motivated this
discussion thread, it's not an alternative in the context of the current
discussion. Regardless, I agree that having such a facility would be
useful.

While I do believe the defaults in gnu-build-system could benefit from
revisiting our current treatment of the check and validate-runpath
phases, advocating for that is not my primary goal with this
discussion.

As someone who's not well-versed in Guix internals, I am simply trying
to understand what an alternate build-system (say, ds-build-system)
would look like. One that allows the user/caller of a package to
determine how to handle:

- whether or not the tests were run, and
- whether or not the tests, if run, passed

Similarly for other such "phases".

One application for such a build-system (which is of interest to me)
would be to "package" the result of some "data"-dependent computations
where the notion of what constitutes a "passing build artifact" is less
clearly defined (e.g., models used for algorithmic decision-making).

-- 
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.