Greg Hogan <c...@greghogan.com> writes: > On Thu, Nov 2, 2023 at 11:26 AM Suhail <suh...@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.
