Re: Guix beyond 1.0: let’s have a roadmap!

[Ricardo Wurmus]

Hi Robert,

>>> - more consistent and useful output — currently it’s very easy to miss the
>>>  actual cause of an error between a lot of noise, e.g. all those 
>>> “recompiling
>>>  scheme module” messages
>>
>> When do you see “recompiling” messages?
>
> Here’s an example:  ~/guix-postgrest$ guix build -L . postgrest
> ;;; note: source file ./bytestring.scm
> ;;;       newer than compiled 
> /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/bytestring.go
> ;;; note: source file ./check.scm
> ;;;       newer than compiled 
> /gnu/store/r6w8vjfdii0pscbp6lmy6siqvzy2lgcn-postgrest/lib/guile/2.2/site-ccache/check.go

This is certainly not normal.  Why do you use “-L .” here?  I don’t
think we recommend this anywhere in the manual.  It does not look like a
common use case.

When we develop packages we do this from a git checkout where we compile
modules with “make” to get rid of these messages.

Having the messages is good, though, because interpreting these files
instead of using the compiled variants comes with a massive drop in
performance.  Since users who don’t develop their own modules won’t ever
see these message I think it is a reasonable reminder to developers to
compile their modules.

> My reason for the suggestion is that my general impression is that error 
> messages
> and useful console output is not a priority that’s generally agreed upon.

It certainly is a priority as demonstrated by the full (but
unfortunately failed) Outreachy internship project to overhaul console
output, which was later picked up by me and later massively extended by
Ludovic to hide build output by default, add spinners, colours, hints,
etc.

Any further work in that direction would be very welcome, though I’m
afraid that the low-hanging fruit has already been plucked.

--
Ricardo