Re: git-fetch without a hash

["Ludovic Courtès" <ludo@gnu.org>]

Hi!

Stephen Paul Weber <singpolyma@singpolyma.net> skribis:

>>> However, there's no real reason that git-fetch *needs* to be
>>> fixed-output in terms of having a hash pre-defined, at least for local
>>> development and other purposes.  So is there a way around this?
>>
>>  • write (package (source (git-checkout …)) …)
>
> This works well.  Now I'm curious how to know what can go in the
> (source) field?  Obviously not just (origin)...

Any “file-like object” can go there: a package (though that makes little
sense), a “computed-file”, etc.

>>> If having a way around it is not desirable should url-fetch consider
>>> this an error as well?
>>
>>I’m not sure; do you have an example where it’s not behaving as
>>expected?
>
> Yes.  When using (sha256 #f) url-fetch still has network access and
> works to download things, which is inconsistent vs other fetchers.

Hmm indeed:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(guix)
scheme@(guile-user)> ,verbosity 3
scheme@(guile-user)> ,build (origin
			      (method url-fetch)
			      (uri "mirror://gnu/hello/hello-2.12.1.tar.gz")
			      (sha256 #f))
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://guix.bordeaux.inria.fr'... 100.0%
building /gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv...

Starting download of /gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz
From https://ftpmirror.gnu.org/gnu/hello/hello-2.12.1.tar.gz...
following redirection to `https://mirror.cyberbits.eu/gnu/hello/hello-2.12.1.tar.gz'...
downloading from https://ftpmirror.gnu.org/gnu/hello/hello-2.12.1.tar.gz ...
 hello-2.12.1.tar.gz  1009KiB                                                                                                                       18.4MiB/s 00:00 [##################] 100.0%
successfully built /gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv
$5 = "/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz"
--8<---------------cut here---------------end--------------->8---

In this case, the derivation uses the “download” built-in builder:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,lower (origin
			      (method url-fetch)
			      (uri "mirror://gnu/hello/hello-2.12.1.tar.gz")
			      (sha256 #f))
$6 = #<derivation /gnu/store/lz34lhyxhq5wxj87fnd465hmwbhv17bn-hello-2.12.1.tar.gz.drv => /gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz 7f3ff487c000>
scheme@(guile-user)> (derivation-outputs $6)
$7 = (("out" . #<<derivation-output> path: "/gnu/store/xfc7gsn10j09bi89ldbpfbppfkcldfy9-hello-2.12.1.tar.gz" hash-algo: sha256 hash: #f recursive?: #f>))
scheme@(guile-user)> (fixed-output-derivation? $6)
$8 = #f
--8<---------------cut here---------------end--------------->8---

As it turns out, guix-daemon turns off the chroot for all built-in
builders, fixed-output or not; quoth ‘build.cc’:

    /* Note: built-in builders are *not* running in a chroot environment so
       that we can easily implement them in Guile without having it as a
       derivation input (they are running under a separate build user,
       though).  */
    useChroot = settings.useChroot && !isBuiltin(drv);

I was actually surprised to see this, this wasn’t really intended.  The
good news is that this is safe AFAICS: there’s only one built-in builder
to date, and that’s “download”.

Now I wonder whether we should keep this “feature” or not.  Probably not.

Thoughts?

Besides, we can think about adding more builtins, such as a
“git-download” builtin, which would let us break potential cycles.

Ludo’.