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

[myglc2 <myglc2@gmail.com>]

On 05/15/2017 at 17:48 Ludovic Courtès writes:

> Hi,
>
> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>
[...]
>> Everyone, I mean everyone, is building guix with different toolsets, i.e,
>> combinations of tools and versions.
>>
>> This is wrong and unguixy.
>
> Yes, I kinda agree, though again, we need to distinguish between
> developers and users (I know I know, the deficiencies of ‘guix pull’
> gives users an incentive to do use the
> checkout/autoreconf/configure/make dance, but let’s put that aside for
> now.)

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

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

Now, if our user thinks they really do want to try making a change, they
first have to wade thru various and confusing config options and set
guix up in a _non-standard_ way. This is currently a large hurdle and
_far from liberating_.

Now there are no doubt different "classes" of guix users that need to be
accommodated. We should think about and agree on a model of what these
classes are and the services that guix provides in each class. Maybe some
of the discussions of channels, potluck, etc can also be fit into such a
framework.

Thinking about these issues I ended up wondering: why don't we use git
checkout in "guix pull" for all classes of user? Then there won't be a
big hurdle to get over when a user decides they want to try editing a
source. In this approach, different user classes would be accommodated
in the documentation structure and with a config option or two. As an
optimization, compiled .go modules can be pulled to minimize user-side
guix source compilation.

ISTM there would be no downside. WDYT?

- George