all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ricardo Wurmus <rekado@elephly.net>
To: myglc2 <myglc2@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2]
Date: Tue, 16 May 2017 17:55:22 +0200	[thread overview]
Message-ID: <87vap0aj9x.fsf@elephly.net> (raw)
In-Reply-To: <86inl127it.fsf_-_@gmail.com>


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.

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

  reply	other threads:[~2017-05-16 15:55 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-15 16:13 Ready for Guile 2.2! Ludovic Courtès
2017-03-15 20:33 ` Pjotr Prins
2017-03-15 20:41 ` Ludovic Courtès
2017-04-20 12:35   ` Ludovic Courtès
2017-04-20 13:10     ` Andy Wingo
2017-04-20 15:21       ` Maxim Cournoyer
2017-04-21 16:05         ` Joshua Branson
2017-04-22 22:20           ` Ludovic Courtès
2017-04-21 21:03         ` Ludovic Courtès
2017-04-24  1:31           ` Maxim Cournoyer
2017-04-21 21:14       ` Ludovic Courtès
2017-03-31 16:34 ` Ludovic Courtès
2017-04-22 22:34 ` ‘guix pull’ vs. transition to Guile 2.2 Ludovic Courtès
2017-04-23 14:09   ` Jan Nieuwenhuizen
2017-04-27 13:25     ` Ludovic Courtès
2017-05-09 21:22   ` Heads-up: " Ludovic Courtès
2017-05-09 22:26     ` myglc2
2017-05-10 12:05       ` Ludovic Courtès
2017-05-10 17:11         ` myglc2
2017-05-11  0:40           ` myglc2
2017-05-11  8:29             ` Ludovic Courtès
2017-05-11  8:50               ` Vincent Legoll
2017-05-11 20:53                 ` Ludovic Courtès
2017-05-11 11:53               ` myglc2
2017-05-11 17:48                 ` ng0
2017-05-11 18:17                   ` ng0
2017-05-11 20:49                     ` Adonay Felipe Nogueira
2017-05-12  8:11                     ` Chris Marusich
2017-05-18 12:32                       ` ng0
2017-05-14 13:50     ` Pjotr Prins
2017-05-14 15:35       ` Pjotr Prins
2017-05-14 16:13         ` Pjotr Prins
2017-05-14 16:28           ` Jan Nieuwenhuizen
2017-05-14 17:29             ` pjotr.public12
2017-05-14 18:30               ` Creating a reliable bootstrap for building from source Pjotr Prins
2017-05-14 21:32                 ` Ludovic Courtès
2017-05-15  1:20                   ` David Pirotte
2017-05-15 13:27                     ` Ludovic Courtès
2017-05-15  7:35                   ` Pjotr Prins
2017-05-15 13:28                     ` Ludovic Courtès
2017-05-17  7:47                       ` Pjotr Prins
2017-05-19  8:58                         ` Ludovic Courtès
2017-05-17  7:52                   ` Pjotr Prins
2017-05-14 21:28       ` Heads-up: transition to Guile 2.2 Ludovic Courtès
2017-05-15  7:26         ` Pjotr Prins
2017-05-15 15:48           ` Ludovic Courtès
2017-05-15 20:24             ` Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2] myglc2
2017-05-16 15:55               ` Ricardo Wurmus [this message]
2017-05-16 20:56                 ` Maxim Cournoyer
2017-05-18 13:54                   ` Katherine Cox-Buday
2017-05-18 15:08                     ` Ludovic Courtès
2017-05-17 12:45                 ` Ludovic Courtès
2017-05-17 17:54                   ` myglc2
2017-05-17 16:06                 ` myglc2
2017-05-17 17:46                   ` myglc2
2017-05-17 23:45                     ` Leo Famulari
2017-05-12  5:41   ` ‘guix pull’ vs. transition to Guile 2.2 Chris Marusich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87vap0aj9x.fsf@elephly.net \
    --to=rekado@elephly.net \
    --cc=guix-devel@gnu.org \
    --cc=myglc2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.