guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#29745] Why should build phases not return unspecified values?


From: Ludovic Courtès
Subject: [bug#29745] Why should build phases not return unspecified values?
Date: Wed, 20 Dec 2017 10:27:16 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Howdy,

Mark H Weaver <address@hidden> skribis:

> I don't think we should rely on every "unspecified value" being treated
> as #true in future versions of Guile.  That is merely an accident of the
> current implementation.
>
> However, I also agree that the current situation is a mess in need of
> cleaning up.
>
> My preference would be to deprecate the practice of returning explicit
> boolean results from phases and snippets, and transition to reporting
> errors exclusively using exceptions.

Yes, that sounds more in line with what we usually do.

> We would create a variant of the 'system*' procedure that raises an
> exception in case of a non-zero status code.

Indeed.  Like Danny wrote, we can already start migrating to ‘invoke’,
which does exactly that.

> Here's a transition plan: We could start by making the new
> exception-throwing 'system*' variant, and switching existing packages to
> use it, while removing the related error-code plumbing.  Once that work
> is done, we could change the code that calls snippets or phase
> procedures to ignore the result of those calls.  Finally, we could
> remove the trailing #t's.
>
> What do you think?

That sounds good to me!

Concretely, we can:

  1. Encourage use of ‘invoke’ when reviewing or writing new package
     definitions;

  2. Gradually migrate packages (we can do a bit of that in
     ‘core-updates’, though we won’t do full rebuilds at this stage).

How does that sound?

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]