help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What exactly guix pull does and why is there a seperate profile at ~


From: Christopher Baines
Subject: Re: What exactly guix pull does and why is there a seperate profile at ~/.config/guix/current ?
Date: Tue, 14 May 2019 18:06:04 +0100
User-agent: mu4e 1.2.0; emacs 26.2

Doron Behar <address@hidden> writes:

>> > According to the documentation, `guix pull` 'updates the distribution
>> > along with the Guix tools'. Does it mean that every time something is
>> > updated in the actual source code of the remote Guix repository, when I
>> > run `guix pull` afterwards my computer builds `guix` and `guix-daemon`
>> > from the ground up? Does it actually run `./configure && make && make
>> > check` behind the scenes on the source files? If so, that's insanely CPU
>> > wasteful and definitely unnecessary.
>>
>> The "source form" for Guix package definitions are snippets of Guile
>> code. Given this, I think it's not as unreasonable to follow the normal
>> processes for building software when getting an updated copy of the
>> package definitions...
>>
>> I don't have a great understanding of it, but running guix pull doesn't
>> just correspond to a single derivation, the task is broken down in to
>> multiple parts, some of which might already be done. There's a more
>> technical description here [2].
>>
>> 2: https://issues.guix.info/issue/27284#43
>>
>> Running guix pull isn't quite the same as running ./configure && make &&
>> make check. In particular, I don't think it uses ./configure, or runs
>> the Guix testsuite.
>
> I've read that 'issue' webpage and it seems the introduced feature
> certainly has given a useful improvement but I'm not sure I understand
> how relevant it is..
>
> I do understand though that since most of Guix is written in Guile,
> packages' definitions are definitely linked to the code that states how
> to build them. I guess that means that most it will have to be
> recompiled after every update in the repository.
>
> It seems that way from the following stdout of `guix pull` I got today:
>
> https://gist.github.com/doronbehar/fe19099502beecf4fb5c4523d8890862
>
> As you can see, it clearly states multiple times the following:
>
>     building /gnu/store/....drv
>     building /gnu/store/....drv
>     building /gnu/store/....drv
>     ...
>
> And it is also reflected when looking at the CPU usage of this command.
> I think there's defiantly room for improving the efficiency of this so
> standard and common process..
>
> Note that I'm saying that under the impression that I've setup
> substitutes correctly - I've authorized substitutes according to the
> documentation and `guix build emacs --dry-run` prints "downloaded" and
> not "will be built".
>
> Thinking about it from a Git development work flow perspective, maybe
> the Guix project should declare that no other thing then package
> additions / version updates should be merged to the master branch and
> that all core development should be done on a `develop` branch. This
> would hopefully have the effect of having `guix pull` only build
> `guix-packages.drv` every time and not everything else as well.

Yeah, I also think there's room for improvement. Just to add more data,
you can see the relevant builds for guix pull on ci.guix.gnu.org here
[1].

As far as I can see, ae5de93 which you pulled was pushed to master at
~05:47, and the build finished at ~12:59 [3]. Assuming this is correct,
that's ~7 hours. I don't think it actually took this long (hopefully),
but it probably wasn't started immediately.

1: http://ci.guix.gnu.org/jobset/guix-modular-master
2: http://ci.guix.gnu.org/eval/5333
3: http://ci.guix.gnu.org/build/1321772

As far as I'm aware, this is more of a software issue with the current
build farm, that could possibly be addressed with some
prioritisation. It probably wouldn't be perfect, but I'd hope if it was
just a bit faster, less people would be impacted by guix pull taking a
while.

>> I think there's also advantages for treating them separately, especially
>> being able to control the generations separately, so you can roll back
>> the .config/guix/current generation without affecting the packages you
>> have installed for example.
>
> I'm not sure I agree. After all, `guix pull && guix package -u` also
> updates guix in ~/.guix-profile so it means that after that, both of
> these `guix` commands in both profiles correspond to the same Guix.. I
> hope someone could convince me I'm wrong.

Maybe I can. Firstly, you probably don't want to have the Guix package
in your profile. If you've got it installed, I'd suggest removing it.

The package for guix in guix normally referrs to a particular commit,
which is updated occasionally. It's in the package version, so you can
check this:

  → guix package --show=guix
  name: guix
  version: 1.0.0-1.326dcbf

This package is mainly used by other packages which have a dependency on
Guix, for example Cuirass, which is the software behind ci.guix.gnu.org.

If I build the guix package, and then run guix describe, I'll get an
error:

  → /gnu/store/cwlghngrh03igf8cfsp2mf49c2l9fnf5-guix-1.0.0-1.326dcbf/bin/guix 
describe
  guix describe: error: failed to determine origin
  hint: Perhaps this `guix' command was not obtained with `guix pull'? Its 
version string is 1.0.0-1.326dcbf.

However, if I run guix describe for the store item generated by guix
pull, I get the expected result.

  → ~/.config/guix/current/bin/guix describe
  Generation 72 May 06 2019 11:27:52    (current)
    guix fc7d632
      repository URL: https://git.savannah.gnu.org/git/guix.git
      branch: master
      commit: fc7d632829e93bd1c6d2db6f99ce22766ff9c67a

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]