From mboxrd@z Thu Jan 1 00:00:00 1970 From: myglc2 Subject: Re: Rethinking guix pull [was Re: Heads-up: transition to Guile 2.2] Date: Wed, 17 May 2017 12:06:26 -0400 Message-ID: <868tlvii2l.fsf@gmail.com> References: <87bmt28qnm.fsf@gnu.org> <87k26chy16.fsf@gnu.org> <87y3u5wwsi.fsf_-_@gnu.org> <20170514135041.GA29369@thebird.nl> <871srrruvi.fsf@gnu.org> <20170515072626.GA963@thebird.nl> <87fug6f7dj.fsf@gnu.org> <86inl127it.fsf_-_@gmail.com> <87vap0aj9x.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49438) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dB1T7-0005LP-O9 for guix-devel@gnu.org; Wed, 17 May 2017 12:06:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dB1T2-00087j-VC for guix-devel@gnu.org; Wed, 17 May 2017 12:06:33 -0400 In-Reply-To: <87vap0aj9x.fsf@elephly.net> (Ricardo Wurmus's message of "Tue, 16 May 2017 17:55:22 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel On 05/16/2017 at 17:55 Ricardo Wurmus writes: > myglc2 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=E2=80=99s UI is famously weird, and th= ere > 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 =E2=80=9Cmake clean-go=E2= =80=9D 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, =E2=80=9Cguix edit=E2=80=9D could do better, e.g. create a new pack= age 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.=20 IMO a better alternative is git submodules and private git branches. > I think that a first step towards improving the experience with =E2=80=9C= guix > pull=E2=80=9D is to build Guix continuously on Hydra and tell =E2=80=9Cgu= ix pull=E2=80=9D 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