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

[Ricardo Wurmus]

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.

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.

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.

> 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.

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.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net