guix build --subsitute-urls does not override guix-daemon run with --no-subsitutes

> From the kind people on #guix, I've heard that "guix build

> --subsitute-urls" should override "guix-daemon --no-subsitutes", but

> it seems it's not doing so for me.

> Here's the situation I ran in to:

>

> While doing a "./pre-inst-env guix pull" I got an error about:

>

> output path `/gnu/store/53lj4z9cavl7n27r89zjnvyd8fk854kj-libgit2-0.26.0.tar.gz' should have sha256 hash `1fdk9yhwvl1w1z71ykzcvgh4nsf8scxcbclz5anh98zpplmhmisa', instead has `

> 1b3figbhp5l83vd37vq6j2narrq4yl9pfw6mw0px0dzb1hz3jqka'

>

> So I tried "./pre-inst-env guix build --source libgit2 --substitute-urls=[https://mirror.hydra.gnu.org"](https://mirror.hydra.gnu.org)

> but it redirected me to https://codeload.github.com/libgit2/libgit2/tar.gz/v0.26.0

> which had the wrong hash.

> On Sun, Oct 08, 2017 at 01:13:16PM -0400, Drashne wrote:

>> From the kind people on #guix, I've heard that "guix build

>> --subsitute-urls" should override "guix-daemon --no-subsitutes", but

>> it seems it's not doing so for me.

>

> The documentation of guix-daemon [0] says this on the subject:

>

> "When the daemon runs with --no-substitutes, clients can still

> explicitly enable substitution via the set-build-options remote

> procedure call (see The Store)."

>

> So, there is a way for unprivileged users to enable substitution for

> themselves even when the local administrator has disabled substitution,

> but it's not via the --substitute-urls mechanism.

>

> I'm closing this bug because I think it's mostly a case of having

> received mistaken advice on #guix.

> Although, I would argue that the current behavior is

> non-intuitive. While true that the manual skim about how one can achieve

> this, the reference to "The Store" is not helpful; it doesn't even

> mention the "set-build-options" procedure. Also, leaving the command

> line to plug directly into Guix's API from Guile is inconvenient at best.

>

> It seems to me that the current behavior of other options that affect

> the guix-daemon operation are that user options override the

> corresponding guix-daemon defaults; maybe that's what lead me and others

> to think that --substitute-urls should attempt to do what the user

> desires?

> Otherwise, we could at least give advice on the output of a Guix command

> when the user passed --substitute-urls when the guix-daemon substitutes

> were disabled to make this clear(er).

> On Fri, Oct 13, 2017 at 09:59:18AM -0400, Maxim Cournoyer wrote:

>> Although, I would argue that the current behavior is

>> non-intuitive. While true that the manual skim about how one can achieve

>> this, the reference to "The Store" is not helpful; it doesn't even

>> mention the "set-build-options" procedure. Also, leaving the command

>> line to plug directly into Guix's API from Guile is inconvenient at best.

>>

>> It seems to me that the current behavior of other options that affect

>> the guix-daemon operation are that user options override the

>> corresponding guix-daemon defaults; maybe that's what lead me and others

>> to think that --substitute-urls should attempt to do what the user

>> desires?

>

> Yeah, maybe it should be changed to be consistent with the behavior of

> the other options.

>> Otherwise, we could at least give advice on the output of a Guix command

>> when the user passed --substitute-urls when the guix-daemon substitutes

>> were disabled to make this clear(er).

>

> Agreed, we should at least do that.

> I don’t know. Substitute sources have to authorized before downloaded

> substitutes are accepted by the daemon. This authorization happens as

> the root user, as it constitutes a system-wide change.