On Thu, 01 Sep 2016 14:37:58 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Mathieu Lirzin <m...@gnu.org> skribis: > > > Eric Bavier <ericbav...@openmailbox.org> writes: > > > >> From: Eric Bavier <bav...@member.fsf.org> > >> > >> 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
