On Tue, May 16, 2017 at 8:55 AM, Ricardo Wurmus <rek...@elephly.net> wrote: > > myglc2 <myg...@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.
+1
