Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]

[myglc2 <myglc2@gmail.com>]

Oops, sent before done, please see corrections ...

On 05/17/2017 at 12:06 myglc2 writes:

> On 05/16/2017 at 17:55 Ricardo Wurmus writes:
>
>> myglc2 <myglc2@gmail.com> writes:
>>
>>> I believe there will be many guix "users" that want to run from git
>>> checkout. They just may not know it, yet. They will want it not just
>>> because they are trying to get around the limitations of git pull.  For
>>> example, even users that don't do development have occasion to...
>>>
>>> - select non-stock package config options
>>>
>>> - need/apply/use patches from guix developers
>>>
>>> - need/apply/use patches from package developers
>>>
>>> - need/apply/use some crazy stuff from a friend
>>
>> For those things I believe it to be better to use the package rewriting
>> framework, i.e. *adding* package variants that have additional patches
>> or modified configuration options.
>
> I don't follow you. Are you talking about (guix) Defining Packages ...
>
>  -- Scheme Procedure: package-input-rewriting REPLACEMENTS
>           [REWRITE-NAME]
>
> ... or something else?
>
>> Using the git checkout directly comes with too many disadvantages for
>> users who are not developers.  Git’s UI is famously weird, and there
>> hardly is anyone who really loves it.
>
> Agreed. But I am not saying you should force guix users to learn git. I
> mean you should leverage git to make guix better. For example, Homebrew
> (https://github.com/Homebrew) users don't know anything about git.
>
>> Using the git checkout also requires the use of “make clean-go” whenever
>> the ABI changes, and occasionally even necessitates re-bootstrapping, or
>> in the case of upgrading to Guile 2.2 re-configuration.
>
> These are shortcomings in how guix uses git, not problems with git
> itself. Changes in the way guix uses git can overcome these.
>
>>> Furthermore, ISTM that current guix packaging is a rather nasty tease:
>>> Our user installs guix/guixSD, does 'guix pull' & 'guix-edit', and what
>>> do they get?
>>>
>>> READ-ONLY source in an editor that BEEPS when they TRY TO CHANGE IT :-(
>>>
>>> Right out of the box this seem contrary to the Guix promise of _freedom_
>>> and _hackability_.
>>
>> True, “guix edit” could do better, e.g. create a new package variant in
>> a user module that inherits from the given package and puts the cursor
>> in the right spot to make changes right there.  Upon saving, the package
>> could be used right away with GUIX_PACKAGE_PATH.
>
> OK, you are jumping to an implementation that uses GUIX_PACKAGE_PATH. I
> am saying you should consider whether an implementation of guix-edit
> based on git may be better.
>
> Confession: I don't use GUIX_PACKAGE_PATH and probably never will: The
> GUIX_PACKAGE_PATH as described in the doc has multiple issues. The fact
> that it is mentioned 7 times in guix.texi is one indication of the
> problem. But the killer is the inherent problem of consistency between
> guix and code on the GUIX_PACKAGE_PATH. Someone trying to use
> GUIX_PACKAGE_PATH to share work with someone else is in for a word or
> hurt. 
>
> IMO a better alternative is git submodules and private git branches.
>
>> I think that a first step towards improving the experience with “guix
>> pull” is to build Guix continuously on Hydra and tell “guix pull” to
>> download that.  Users would no longer have to wait for compilation on
>> their local machines, removing a big incentive to go with a git
>> checkout.  Maybe we should do this first to stop the worst problems,
>> buying us a bit more time to implement channels.

Are you saying that users currently use the git checkout so they can
"stay put" on an old commit?

Are you saying that the version delivered by guix pull should be delayed
WRT the most current guix git repo master commit to allow hydra to
complete the build? If so +1

> I have been actively using guix pull and git pull for the last year. My
> "hillbilly impression" is that the problem with hydra that it is almost
> always either
[...]
- behind: user guix version is old and no longer in hydra's store

- ahead: user just did 'guix pull' but hydra hasn't build it.  I think
  you addressed this above

- new-commit: a developer has done git pull and hydra hasn't looked at
  it yet

- patch: a developer applies a patch from another developer

ISTM these can be addressed ...

- behind: save everything hydra builds, or at least the last few
  installation images. Can't we just accomplish this by never doing
  "guix gc" on hydra?

- new-commit: Here we want hydra to build every commit that lands in the
  guix git repo, prioritizing some branches (e.g. master) over others.

An approach that splits hydra's resources between building for ahead and
new-commit branches would be very nice to have, EH? ;-) 

WDYT? - George