bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10

bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10

[zimoun]

Hi,

Using 3dcc74d, I get an unexpected behaviour.  First, all expected:

--8<---------------cut here---------------start------------->8---
$ guix build ghc@8.10 -n
122,4 MB would be downloaded:
   /gnu/store/p8rk5cp1p4b2zky4zj1shfqb11qb5nmk-ghc-8.10.7-doc
   /gnu/store/i92h6i23rnvrvn7xva6w9x7gjkljmfws-ghc-8.10.7

$ guix build ghc@8.4 -n
/gnu/store/5gp4k7ly1smhkx95rhq21nvxmyg687bv-ghc-8.4.4-doc
/gnu/store/wxfr2naibx3qpy4w243a7ga98mchf6g3-ghc-8.4.4
--8<---------------cut here---------------end--------------->8---

I have ghc@8.4 in my local store, but not ghc@8.10.  In addition, no
path between ghc@8.4 and ghc@8.10,

--8<---------------cut here---------------start------------->8---
$ guix graph --path ghc@8.4 ghc@8.10
guix graph: error: no path from 'ghc@8.4.4' to 'ghc@8.10.7'
--8<---------------cut here---------------end--------------->8---

Even, ghc@8.4 is used in the bootstrap chain of ghc@8.10,

--8<---------------cut here---------------start------------->8---
$ guix graph --path ghc@8.10 ghc@8.4
ghc@8.10.7
ghc@8.8.4
ghc@8.6.5
ghc@8.4.4
--8<---------------cut here---------------end--------------->8---

However, tandam!

--8<---------------cut here---------------start------------->8---
$ guix shell -C ghc@8.4
The following derivation will be built:
   /gnu/store/rx0spryh76az0ll6ddy7f7hy8ykhglnh-profile.drv

117,7 MB will be downloaded
 ghc-8.10.7  112.3MiB                                                                                                         3.3MiB/s 00:01 [                  ]   1.9%  C-c C-c
--8<---------------cut here---------------end--------------->8---

From the profile.drv, the culprit is identified:
/gnu/store/…-ghc-package-cache.drv,

--8<---------------cut here---------------start------------->8---
Derive
([("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache","","")]
 ,[("/gnu/store/8m7vppxy4l824yk4036iisk2zy7qzgcx-ghc-8.4.4.drv",["out"])
   ,("/gnu/store/bc5cm1g1b884nvgiysq8x0i0wxplkqhl-ghc-8.10.7.drv",["out"])
   ,("/gnu/store/m0nbbk3vgl637ibrz7z72r5v0dkswpi2-guile-3.0.7.drv",["out"])
   ,("/gnu/store/qcksap17gs36gpnjj3by4d7r7yxfq405-module-import-compiled.drv",["out"])]
 ,["/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import"]
 ,"x86_64-linux","/gnu/store/fidl08nms5v63lkqv627zibxpd85zxqb-guile-3.0.7/bin/guile",["--no-auto-compile","-L","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import","-C","/gnu/store/n7687sw6nkrhpjkdgysgz7baihzipgl0-module-import-compiled","/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder"]
 ,[("allowSubstitutes","0")
   ,("guix properties","((type . profile-hook) (hook . ghc-package-cache))")
   ,("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache")
   ,("preferLocalBuild","1")])
--8<---------------cut here---------------end--------------->8---


From my perspective, it is a bug from (guix profiles)
’ghc-package-cache-file’ which always includes ’ghc’, currently pointing
to ghc@8.10.

--8<---------------cut here---------------start------------->8---
  (define ghc                                     ;lazy reference
    (module-ref (resolve-interface '(gnu packages haskell)) 'ghc))
--8<---------------cut here---------------end--------------->8---

Well, the fix is not jumping to my eyes.  If someone has an idea to
conditionally remove this reference to ’ghc’?


Cheers,
simon

bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

>>From the profile.drv, the culprit is identified:
> /gnu/store/…-ghc-package-cache.drv,
>
> Derive
> ([("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache","","")]
>  ,[("/gnu/store/8m7vppxy4l824yk4036iisk2zy7qzgcx-ghc-8.4.4.drv",["out"])
>    ,("/gnu/store/bc5cm1g1b884nvgiysq8x0i0wxplkqhl-ghc-8.10.7.drv",["out"])
>    ,("/gnu/store/m0nbbk3vgl637ibrz7z72r5v0dkswpi2-guile-3.0.7.drv",["out"])
>    ,("/gnu/store/qcksap17gs36gpnjj3by4d7r7yxfq405-module-import-compiled.drv",["out"])]
>  ,["/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import"]
>  ,"x86_64-linux","/gnu/store/fidl08nms5v63lkqv627zibxpd85zxqb-guile-3.0.7/bin/guile",["--no-auto-compile","-L","/gnu/store/4j2xcm5s0hvmpjm8fdbmb02ipvr6wyxn-module-import","-C","/gnu/store/n7687sw6nkrhpjkdgysgz7baihzipgl0-module-import-compiled","/gnu/store/45dpf18lzvzs6sbmihifw6ch9p6y20yr-ghc-package-cache-builder"]
>  ,[("allowSubstitutes","0")
>    ,("guix properties","((type . profile-hook) (hook . ghc-package-cache))")
>    ,("out","/gnu/store/mcmwdg13f5rc9vdklgbmsn6h84bgdp3q-ghc-package-cache")
>    ,("preferLocalBuild","1")])
>
>
>
>>From my perspective, it is a bug from (guix profiles)
> ’ghc-package-cache-file’ which always includes ’ghc’, currently pointing
> to ghc@8.10.
>
>   (define ghc                                     ;lazy reference
>     (module-ref (resolve-interface '(gnu packages haskell)) 'ghc))
>
> Well, the fix is not jumping to my eyes.  If someone has an idea to
> conditionally remove this reference to ’ghc’?

Is it a problem that the latest GHC is used to build the package cache?
(Apart from being surprising and suboptimal.)

Some profile hooks, such as ‘gdk-pixbuf-loaders-cache-file’, use the
package available in the closure (gdk-pixbuf in this case) rather than
the latest version.  It’s a bit of a hack, but if required, we could do
that.

Ludo’.

bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10

[zimoun]

Hi,

On Tue, 11 Jan 2022 at 11:18, Ludovic Courtès <ludo@gnu.org> wrote:

> Is it a problem that the latest GHC is used to build the package cache?
> (Apart from being surprising and suboptimal.)

Functionally, it appears to be not a blocking problem.  However,
suboptimal means concretely 110+ MB of additional download; well it just
doubles the size of the download.

About the surprise, if one is confident with their Guix skill, then they
look for a bug Guix-side; if one is less confident, then they look for a
twist in their config.  In both cases, it is a diversion – let as the
reader’s judgment if this diversion is fun or a waste of time. :-)


> Some profile hooks, such as ‘gdk-pixbuf-loaders-cache-file’, use the
> package available in the closure (gdk-pixbuf in this case) rather than
> the latest version.  It’s a bit of a hack, but if required, we could do
> that.

What other Haskellers think about the issue?  Fix or document this
surprising behaviour?


Cheers,
simon

bug#53162: ’guix shell ghc@8.4’ downloads ghc@8.10

[Ludovic Courtès]

Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

> On Tue, 11 Jan 2022 at 11:18, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Is it a problem that the latest GHC is used to build the package cache?
>> (Apart from being surprising and suboptimal.)
>
> Functionally, it appears to be not a blocking problem.  However,
> suboptimal means concretely 110+ MB of additional download; well it just
> doubles the size of the download.

Understood.

> About the surprise, if one is confident with their Guix skill, then they
> look for a bug Guix-side; if one is less confident, then they look for a
> twist in their config.  In both cases, it is a diversion – let as the
> reader’s judgment if this diversion is fun or a waste of time. :-)

Yes, but that’s not very different from installing mpv and setting
downloads of ffmpeg, rav1e, rust, and all sorts of things the user
doesn’t necessarily know about.

So to me we should first look at (1) compatibility (make sure the
package cache is valid), and (2) efficiency (avoid downloading too
much).

Ludo’.