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

[myglc2]

On 05/16/2017 at 17:55 Ricardo Wurmus writes:

> myglc2 <address@hidden> 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.

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

- "ahead" of the user (e.g., files that the user needs are no longer in
   hydra's store) or

- "behind" the user (e.g. a developer that has just pulled someone
   else's commit, which aren't built yet).

Can't the "ahead" problem be fixed by just saving everything hydra has
ever built? Disks are cheap aren't they?

As regards the "behind" problem, can't this be fixed by having 'guix
pull' deliver only the git commits that are completely built?

- George