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. When I use ./pre-inst-env, I feel like I have my wizard hat on and no safety belt. ;-) > 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. Ludo’.
