Hi!
Stephen Paul Weber <singpol...@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’.
