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

[Robert Vollmert]

> On 9. Jul 2019, at 12:22, Ricardo Wurmus <address@hidden> wrote:
> 
> 
> 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?

~/guix-postgrest is a git repository that houses some in-development packages 
of mine.
E.g. there’s a file postgrest.scm that has the definition of the postgrest 
package,
and the file check.scm that has definitions of a number haskell dependencies 
that
are not in guix proper yet.

guix build -L . <package-name>

then seems like the straightforward way to interactively test that package 
definition
without going through any git push, guix pull etc.

> Having the messages is good, though, because interpreting these files
> instead of using the compiled variants comes with a massive drop in
> performance.

Why doesn’t guile silently do the right thing instead?

Cheers
Robert