Re: [PATCH] Clean all .go in clean-go

[Eric Bavier]

On Thu, 01 Sep 2016 14:37:58 +0200
address@hidden (Ludovic Courtès) wrote:

> Mathieu Lirzin <address@hidden> skribis:
> 
> > Eric Bavier <address@hidden> writes:
> >  
> >> From: Eric Bavier <address@hidden>
> >>
> >> I encountered a runtime error recently while running `guix system
> >> reconfigure`.  Thinking this might be because of an ABI break I ran `make 
> >> clean-go && make` before trying again, with the same result.
> >>
> >> It turns out a module had been renamed, in this case fish.scm to 
> >> shells.scm,
> >> but I had overlooked this and failed to update the list of modules in my
> >> config.scm's (use-package-modules ...) statement.  However, I still had a
> >> stale fish.go sitting in my build directory, which `make clean-go` had 
> >> failed
> >> to clean up, and guix happily loaded it.
> >>
> >> I believe the following patch is an appropriate way to avoid such errors in
> >> the future.  
> >
> > AIUI the main problem is that the API for defining "config.scm" is not
> > stable because of the package modules renames.  Since package names are
> > more stable, I think that configuration files should import (gnu
> > packages) and use 'specification->package' when possible to resolve
> > packages, instead of relying on the module names.  Maybe we should fix
> > the "config.scm" documentation?  
> 
> Look, the fine manual already mentions it (info "(guix) Using the
> Configuration System").  :-)
> 
> I’ve also been hit by what Eric describes though.  However, the indented
> use case is that people use ‘guix pull’, in which case they cannot have
> this sort of problem; at worse they get “no code for module” or similar.

Sure, but we also regularly recommend users to maintain a git checkout.

> When I use ./pre-inst-env, I feel like I have my wizard hat on and no
> safety belt.  ;-)

This is in fact what I do most times.

> 
> > In regards of the .go files remaining in the build directory, I agree
> > that this is not good, however I don't think it is worth trying to fix
> > this issue which equally applies to every file generated by Make.  Using
> > wildcards can be tempting in such cases but it can lead to accidental
> > file deletions which is worse IMO.  As a consequence I would prefer
> > keeping the current 'clean-go' rule.  
> 
> I sympathize with that.

How about simply printing  a warning if there are any .go files laying
around after a `make clean` or `make clean-go`?

`~Eric