[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Clean all .go in clean-go
From: |
Ludovic Courtès |
Subject: |
Re: [PATCH] Clean all .go in clean-go |
Date: |
Thu, 01 Sep 2016 14:37:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
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.
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’.