[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#64858: ~guix shell -C -f guix.scm …~ should not always need ~--rebui
From: |
Ludovic Courtès |
Subject: |
bug#64858: ~guix shell -C -f guix.scm …~ should not always need ~--rebuild-cache~ option to build the expected environment. |
Date: |
Thu, 12 Oct 2023 17:25:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Pierre-Henry,
Pierre-Henry Fröhring <phfrohring@deeplinks.com> skribis:
> $ guix shell -C -f guix.scm ripgrep fd coreutils emacs
[...]
> This very file (~pkgex.el.org~) is updated with this content then the
> package is
> built again.
>
> #+begin_example
> $ make build # equivalent to: guix build -f guix.scm
> …
> /gnu/store/8k18bghzcijbps8kix3wqp34x4smfc5l-pkgex-1
> #+end_example
>
>
> ** pkgex-1 -> /gnu/store/0yk3xz85…
>
> Unexpectedly, the package linked from within the container using the same
> command as above is not updated, we observe:
I don’t fully understand the setup, but I can at least explain what you
can expect.
When using ‘-f guix.scm’, ‘guix shell’ caches based on the mtime of
‘guix.scm’: if ‘guix.scm’ is modified, then the cache is invalidated,
otherwise the cache is considered up-to-date and used.
IIUC, you’re modifying a different file, ‘pkgex.el.org’. ‘guix shell’
does not know about it and thus goes ahead and reuses the previous
value.
I guess the current behavior is good when you’re doing:
guix shell -D -f guix.scm
which is the primary use case that comes to mind, but it’s inappropriate
when doing:
guix shell -f guix.scm
in cases where ‘guix.scm’ defines a package with $PWD as its source.
I guess we could maybe try to special-case that in
‘profile-cached-gc-root’.
Ludo’.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#64858: ~guix shell -C -f guix.scm …~ should not always need ~--rebuild-cache~ option to build the expected environment.,
Ludovic Courtès <=