Add guix install command

Add guix install command

[Andy Wingo]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Hi,

I think Guix's tooling is OK but it could be better.  As a user -- and
I'm really trying to be a user and not a developer :-) -- my main
interactions with a Guix system are installing, searching, and
upgrading.  Sometimes mucking about with profiles, sometimes more
involved things, but usually installing, searching, and upgrading, in
that order.

So to me the guix package command is a bit overkill for my uses and I
always forget which options are which (often typing "guix install" only
to be told there is no such thing, likewise for search, and is it search
with big -S or little -s?).  I spend a lot of my time with guix looking
at the --help output (and I still don't know why "guix help package"
doesn't give me anything useful).

I know that guix package is definitely the core interface, and the one
that Guix wants.  However I would like to plead for adding more
special-purpose subset interfaces :)  They will make user life better.

Attached is a patch to implement "guix install".  It just copies over
functionality from guix package.  We could refactor more but I would
start with this as it is; when things need changes is the time to
refactor, at least for me.  What do you think? :)

Regards,

Andy


[-- Attachment #2: 0001-Add-guix-install-command.patch --]
[-- Type: text/plain, Size: 26846 bytes --]

From 7f1ac0b748a40b0a093d20c27401f305ce6aec9f Mon Sep 17 00:00:00 2001
From: Andy Wingo <wingo@igalia.com>
Date: Wed, 5 Aug 2015 11:27:48 +0200
Subject: [PATCH] Add guix install command

* guix/scripts/install.scm: New file.
* doc/guix.texi: Change guix package -i invocations to use guix install.
  (Features): Add links to "Invoking guix install".
  (Invoking guix install): New section.
  (Invoking guix package): Link back to Invoking guix install.

* doc.am:
* NEWS:
* Makefile.am: Update.
---
 Makefile.am              |   1 +
 NEWS                     |   2 +-
 doc.am                   |   1 +
 doc/guix.texi            | 125 +++++++++++++---
 guix/scripts/install.scm | 377 +++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 482 insertions(+), 24 deletions(-)
 create mode 100644 guix/scripts/install.scm

diff --git a/Makefile.am b/Makefile.am
index ada4cbe..47fa243 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -104,6 +104,7 @@ MODULES =					\
   guix/scripts/build.scm			\
   guix/scripts/archive.scm			\
   guix/scripts/import.scm			\
+  guix/scripts/install.scm			\
   guix/scripts/package.scm			\
   guix/scripts/gc.scm				\
   guix/scripts/hash.scm				\
diff --git a/NEWS b/NEWS
index e33e2ac..c72c86a 100644
--- a/NEWS
+++ b/NEWS
@@ -14,7 +14,7 @@ Please send Guix bug reports to bug-guix@gnu.org.
 
 ** Package management
 
-*** New ‘guix edit’ and ‘guix size’ commands
+*** New ‘guix edit’, ‘guix size’, and ‘guix install’ commands
 *** New ‘--manifest’ option for ‘guix package’, for declarative profiles
 *** Similarly, new ‘M-x guix-apply-manifest’ for the Emacs UI
 *** Emacs support now includes completion for ‘guix’ commands in shell-mode
diff --git a/doc.am b/doc.am
index 02b80ec..7f21ec3 100644
--- a/doc.am
+++ b/doc.am
@@ -107,6 +107,7 @@ SUBCOMMANDS :=					\
   gc						\
   hash						\
   import					\
+  install					\
   lint						\
   package					\
   publish					\
diff --git a/doc/guix.texi b/doc/guix.texi
index bcf07a6..2b09a30 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -100,7 +100,8 @@ Setting Up the Daemon
 Package Management
 
 * Features::                    How Guix will make your life brighter.
-* Invoking guix package::       Package installation, removal, etc.
+* Invoking guix install::       Package installation.
+* Invoking guix package::       General-purpose package management tool.
 * Emacs Interface::             Package management from Emacs.
 * Substitutes::                 Downloading pre-built binaries.
 * Packages with Multiple Outputs::  Single source package, multiple outputs.
@@ -931,7 +932,7 @@ variable (@pxref{Locale Names, @code{LOCPATH},, libc, The GNU C Library
 Reference Manual}):
 
 @example
-$ guix package -i glibc-locales
+$ guix install glibc-locales
 $ export LOCPATH=$HOME/.guix-profile/lib/locale
 @end example
 
@@ -969,7 +970,8 @@ interface in Emacs (@pxref{Emacs Interface}).
 
 @menu
 * Features::                    How Guix will make your life brighter.
-* Invoking guix package::       Package installation, removal, etc.
+* Invoking guix install::       Package installation.
+* Invoking guix package::       General-purpose package management tool.
 * Emacs Interface::             Package management from Emacs.
 * Substitutes::                 Downloading pre-built binaries.
 * Packages with Multiple Outputs::  Single source package, multiple outputs.
@@ -1000,16 +1002,20 @@ simply continues to point to
 @file{/gnu/store/@dots{}-gcc-4.8.0/bin/gcc}---i.e., both versions of GCC
 coexist on the same system without any interference.
 
-The @command{guix package} command is the central tool to manage
-packages (@pxref{Invoking guix package}).  It operates on those per-user
+The central tool to manage packages is the @command{guix package}
+command (@pxref{Invoking guix package}).  There is also a @command{guix
+install} command for the subset of @code{guix package} functionality
+that deals with package installation (@pxref{Invoking guix install}).
+The Guix package installation commands operate on those per-user
 profiles, and can be used @emph{with normal user privileges}.
 
-The command provides the obvious install, remove, and upgrade
-operations.  Each invocation is actually a @emph{transaction}: either
-the specified operation succeeds, or nothing happens.  Thus, if the
-@command{guix package} process is terminated during the transaction,
-or if a power outage occurs during the transaction, then the user's
-profile remains in its previous state, and remains usable.
+The @code{guix package} command provides the obvious install, remove,
+and upgrade operations.  Each invocation is actually a
+@emph{transaction}: either the specified operation succeeds, or nothing
+happens.  Thus, if the @command{guix package} process is terminated
+during the transaction, or if a power outage occurs during the
+transaction, then the user's profile remains in its previous state, and
+remains usable.
 
 In addition, any package transaction may be @emph{rolled back}.  So, if,
 for example, an upgrade installs a new version of a package that turns
@@ -1052,14 +1058,81 @@ a package to quickly set up the right development environment for their
 package, without having to manually install the package's dependencies
 in their profile (@pxref{Invoking guix environment}).
 
+@node Invoking guix install
+@section Invoking @command{guix install}
+
+The @command{guix install} command allows users to install packages.  It
+operates only on the user's own profile, and works with normal user
+privileges (@pxref{Features}).  Its syntax is:
+
+@example
+guix install @var{options} @var{package} @dots{}
+@end example
+
+For example, to install @code{guile} and @code{emacs}, simply run:
+
+@example
+guix install guile emacs
+@end example
+
+Each @var{package} may specify either a simple package name, such as
+@code{guile}, or a package name followed by a hyphen and version number,
+such as @code{guile-1.8.8} or simply @code{guile-1.8} (in the latter
+case, the newest version prefixed by @code{1.8} is selected.)
+
+If no version number is specified, the
+newest available version will be selected.  In addition, @var{package}
+may contain a colon, followed by the name of one of the outputs of the
+package, as in @code{gcc:doc} or @code{binutils-2.22:lib}
+(@pxref{Packages with Multiple Outputs}).  Packages with a corresponding
+name (and optionally version) are searched for among the GNU
+distribution modules (@pxref{Package Modules}).
+
+@cindex propagated inputs
+Sometimes packages will require other packages (@dfn{propagated inputs})
+to also be installed into a profile.
+
+Upon completion of the @command{guix install} command, a new profile is
+created, but previous @dfn{generations} of the profile remain available,
+should the user want to roll back.
+
+@xref{Invoking guix package}, for more on user profiles, how to add a
+profile to a user's environment (@code{PATH} and so on), and package
+management in general.  The @command{guix install} command is a simple
+form of @command{guix package}.
+
+The @var{options} can be among the following:
+
+@table @code
+
+@item --from-expression=@var{exp}
+@itemx -e @var{exp}
+Install the package @var{exp} evaluates to.  @xref{Invoking guix
+package}, for more on package expressions, where this option is called
+@code{--install-from-expression}.
+
+@item --profile=@var{profile}
+@itemx -p @var{profile}
+Use @var{profile} instead of the user's default profile.
+
+@item --verbose
+Produce verbose output.  In particular, emit the environment's build log
+on the standard error port.
+
+@end table
+
+Finally, since @command{guix install} may actually start build
+processes, it supports all the common build options that @command{guix
+build} supports (@pxref{Invoking guix build, common build options}).
+
 @node Invoking guix package
 @section Invoking @command{guix package}
 
 The @command{guix package} command is the tool that allows users to
 install, upgrade, and remove packages, as well as rolling back to
-previous configurations.  It operates only on the user's own profile,
-and works with normal user privileges (@pxref{Features}).  Its syntax
-is:
+previous configurations.  Like the simple @command{guix install}
+command, it operates only on the user's own profile, and works with
+normal user privileges (@pxref{Features}).  Its syntax is:
 
 @example
 guix package @var{options}
@@ -1116,10 +1189,16 @@ The @var{options} can be among the following:
 @itemx -i @var{package} @dots{}
 Install the specified @var{package}s.
 
-Each @var{package} may specify either a simple package name, such as
-@code{guile}, or a package name followed by a hyphen and version number,
-such as @code{guile-1.8.8} or simply @code{guile-1.8} (in the latter
-case, the newest version prefixed by @code{1.8} is selected.)
+For the simple use case of just installing one or more packages, the
+@command{guix install} command offers a subset of the @command{guix
+package -i} functionality in a simpler interface.  @xref{Invoking guix
+install}, for more.
+
+As in @command{guix install}, each @var{package} may specify either a
+simple package name, such as @code{guile}, or a package name followed by
+a hyphen and version number, such as @code{guile-1.8.8} or simply
+@code{guile-1.8} (in the latter case, the newest version prefixed by
+@code{1.8} is selected.)
 
 If no version number is specified, the
 newest available version will be selected.  In addition, @var{package}
@@ -1555,7 +1634,7 @@ like to discuss this project, join us on @email{guix-devel@@gnu.org}.
 
 Often, packages defined in Guix have a single @dfn{output}---i.e., the
 source package leads exactly one directory in the store.  When running
-@command{guix package -i glibc}, one installs the default output of the
+@command{guix install glibc}, one installs the default output of the
 GNU libc package; the default output is called @code{out}, but its name
 can be omitted as shown in this command.  In this particular case, the
 default output of @code{glibc} contains all the C header files, shared
@@ -1571,13 +1650,13 @@ separate output, called @code{doc}.  To install the main GLib output,
 which contains everything but the documentation, one would run:
 
 @example
-guix package -i glib
+guix install glib
 @end example
 
 The command to install its documentation is:
 
 @example
-guix package -i glib:doc
+guix install glib:doc
 @end example
 
 Some packages install programs with different ``dependency footprints''.
@@ -6571,7 +6650,7 @@ installs the debugging information for the GNU C Library and for GNU
 Guile:
 
 @example
-guix package -i glibc:debug guile:debug
+guix install glibc:debug guile:debug
 @end example
 
 GDB must then be told to look for debug files in the user's profile, by
@@ -6678,7 +6757,7 @@ module exports a variable named @code{emacs}, which is bound to a
 
 The @code{(gnu packages @dots{})} module name space is
 automatically scanned for packages by the command-line tools.  For
-instance, when running @code{guix package -i emacs}, all the @code{(gnu
+instance, when running @code{guix install emacs}, all the @code{(gnu
 packages @dots{})} modules are scanned until one that exports a package
 object whose name is @code{emacs} is found.  This package search
 facility is implemented in the @code{(gnu packages)} module.
diff --git a/guix/scripts/install.scm b/guix/scripts/install.scm
new file mode 100644
index 0000000..4cff574
--- /dev/null
+++ b/guix/scripts/install.scm
@@ -0,0 +1,377 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2012, 2013, 2014, 2015 Ludovic Courtès <ludo@gnu.org>
+;;; Copyright © 2013 Nikita Karetnikov <nikita@karetnikov.org>
+;;; Copyright © 2013, 2015 Mark H Weaver <mhw@netris.org>
+;;; Copyright © 2014 Alex Kost <alezost@gmail.com>
+;;; Copyright © 2015 Andy Wingo <wingo@igalia.com>
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (guix scripts install)
+  #:use-module (guix ui)
+  #:use-module (guix store)
+  #:use-module (guix derivations)
+  #:use-module (guix packages)
+  #:use-module (guix profiles)
+  #:use-module (guix search-paths)
+  #:use-module (guix monads)
+  #:use-module (guix utils)
+  #:use-module (guix config)
+  #:use-module (guix scripts build)
+  #:use-module (guix scripts package)
+  #:use-module ((guix build utils) #:select (mkdir-p))
+  #:use-module (ice-9 format)
+  #:use-module (ice-9 match)
+  #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-11)
+  #:use-module (srfi srfi-26)
+  #:use-module (srfi srfi-37)
+  #:use-module (gnu packages)
+  #:use-module (gnu packages base)
+  #:use-module (gnu packages guile)
+  #:export (guix-install))
+
+(define %store
+  (make-parameter #f))
+
+\f
+;;;
+;;; Profiles.
+;;;
+
+(define %user-profile-directory
+  (and=> (getenv "HOME")
+         (cut string-append <> "/.guix-profile")))
+
+(define %profile-directory
+  (string-append %state-directory "/profiles/"
+                 (or (and=> (or (getenv "USER")
+                                (getenv "LOGNAME"))
+                            (cut string-append "per-user/" <>))
+                     "default")))
+
+(define %current-profile
+  ;; Call it `guix-profile', not `profile', to allow Guix profiles to
+  ;; coexist with Nix profiles.
+  (string-append %profile-directory "/guix-profile"))
+
+(define (canonicalize-profile profile)
+  "If PROFILE is %USER-PROFILE-DIRECTORY, return %CURRENT-PROFILE.  Otherwise
+return PROFILE unchanged.  The goal is to treat '-p ~/.guix-profile' as if
+'-p' was omitted."                           ; see <http://bugs.gnu.org/17939>
+  (if (and %user-profile-directory
+           (string=? (canonicalize-path (dirname profile))
+                     (dirname %user-profile-directory))
+           (string=? (basename profile) (basename %user-profile-directory)))
+      %current-profile
+      profile))
+
+(define (user-friendly-profile profile)
+  "Return either ~/.guix-profile if that's what PROFILE refers to, directly or
+indirectly, or PROFILE."
+  (if (and %user-profile-directory
+           (false-if-exception
+            (string=? (readlink %user-profile-directory) profile)))
+      %user-profile-directory
+      profile))
+
+(define (link-to-empty-profile store generation)
+  "Link GENERATION, a string, to the empty profile."
+  (let* ((drv  (run-with-store store
+                 (profile-derivation (manifest '()))))
+         (prof (derivation->output-path drv "out")))
+    (when (not (build-derivations store (list drv)))
+          (leave (_ "failed to build the empty profile~%")))
+
+    (switch-symlinks generation prof)))
+
+\f
+;;;
+;;; Command-line options.
+;;;
+
+(define %default-options
+  ;; Alist of default option values.
+  `((profile . ,%current-profile)
+    (max-silent-time . 3600)
+    (verbosity . 0)
+    (substitutes? . #t)))
+
+(define (show-help)
+  (display (_ "Usage: guix install [OPTION]... PACKAGE...
+Install packages.\n"))
+  (display (_ "
+  -e, --from-expression=EXP
+                         install the package EXP evaluates to"))
+  (display (_ "
+  -p, --profile=PROFILE  use PROFILE instead of the user's default profile"))
+  (newline)
+  (display (_ "
+      --verbose          produce verbose output"))
+  (newline)
+  (show-build-options-help)
+  (newline)
+  (display (_ "
+  -h, --help             display this help and exit"))
+  (display (_ "
+  -V, --version          display version information and exit"))
+  (newline)
+  (display (_ "
+For more involved use cases, including transactions, package removals,
+manifests, and other operations, see the more general \"guix package\"
+command."))
+  (newline)
+  (show-bug-report-information))
+
+(define %options
+  ;; Specification of the command-line options.
+  (cons* (option '(#\h "help") #f #f
+                 (lambda args
+                   (show-help)
+                   (exit 0)))
+         (option '(#\V "version") #f #f
+                 (lambda args
+                   (show-version-and-exit "guix package")))
+         (option '(#\e "from-expression") #t #f
+                 (lambda (opt name arg result arg-handler)
+                   (values (alist-cons 'install (read/eval-package-expression arg)
+                                       result)
+                           #f)))
+         (option '(#\p "profile") #t #f
+                 (lambda (opt name arg result arg-handler)
+                   (values (alist-cons 'profile (canonicalize-profile arg)
+                                       (alist-delete 'profile result))
+                           #f)))
+         (option '(#\n "dry-run") #f #f
+                 (lambda (opt name arg result arg-handler)
+                   (values (alist-cons 'dry-run? #t result)
+                           #f)))
+         (option '("verbose") #f #f
+                 (lambda (opt name arg result arg-handler)
+                   (values (alist-cons 'verbose? #t result)
+                           #f)))
+         %standard-build-options))
+
+(define (options->installable opts manifest)
+  "Given MANIFEST, the current manifest, and OPTS, the result of 'args-fold',
+return the new list of manifest entries."
+  (define (package->manifest-entry* package output)
+    (check-package-freshness package)
+    ;; When given a package via `-e', install the first of its
+    ;; outputs (XXX).
+    (package->manifest-entry package output))
+
+  (define packages-to-install
+    (filter-map (match-lambda
+                 (('install . (? package? p))
+                  (list p "out"))
+                 (('install . (? string? spec))
+                  (and (not (store-path? spec))
+                       (let-values (((package output)
+                                     (specification->package+output spec)))
+                         (and package (list package output)))))
+                 (_ #f))
+                opts))
+
+  (define to-install
+    (append (map (match-lambda
+                  ((package output)
+                   (package->manifest-entry* package output)))
+                 packages-to-install)
+            (filter-map (match-lambda
+                         (('install . (? package?))
+                          #f)
+                         (('install . (? store-path? path))
+                          (let-values (((name version)
+                                        (package-name->name+version
+                                         (store-path-package-name path))))
+                            (manifest-entry
+                             (name name)
+                             (version version)
+                             (output #f)
+                             (item path))))
+                         (_ #f))
+                        opts)))
+
+  to-install)
+
+(define (register-gc-root store profile)
+  "Register PROFILE, a profile generation symlink, as a GC root, unless it
+doesn't need it."
+  (define absolute
+    ;; We must pass the daemon an absolute file name for PROFILE.  However, we
+    ;; cannot use (canonicalize-path profile) because that would return us the
+    ;; target of PROFILE in the store; using a store item as an indirect root
+    ;; would mean that said store item will always remain live, which is not
+    ;; what we want here.
+    (if (string-prefix? "/" profile)
+        profile
+        (string-append (getcwd) "/" profile)))
+
+  (add-indirect-root store absolute))
+
+(define (readlink* file)
+  "Call 'readlink' until the result is not a symlink."
+  (define %max-symlink-depth 50)
+
+  (let loop ((file  file)
+             (depth 0))
+    (define (absolute target)
+      (if (absolute-file-name? target)
+          target
+          (string-append (dirname file) "/" target)))
+
+    (if (>= depth %max-symlink-depth)
+        file
+        (call-with-values
+            (lambda ()
+              (catch 'system-error
+                (lambda ()
+                  (values #t (readlink file)))
+                (lambda args
+                  (let ((errno (system-error-errno args)))
+                    (if (or (= errno EINVAL))
+                        (values #f file)
+                        (apply throw args))))))
+          (lambda (success? target)
+            (if success?
+                (loop (absolute target) (+ depth 1))
+                file))))))
+
+\f
+;;;
+;;; Entry point.
+;;;
+
+(define (guix-install . args)
+  (define (handle-argument arg result)
+    ;; Anything that's not an option is a package to install.
+    (alist-cons 'install arg result))
+
+  (define (ensure-default-profile)
+    ;; Ensure the default profile symlink and directory exist and are
+    ;; writable.
+
+    (define (rtfm)
+      (format (current-error-port)
+              (_ "Try \"info '(guix) Invoking guix package'\" for \
+more information.~%"))
+      (exit 1))
+
+    ;; Create ~/.guix-profile if it doesn't exist yet.
+    (when (and %user-profile-directory
+               %current-profile
+               (not (false-if-exception
+                     (lstat %user-profile-directory))))
+      (symlink %current-profile %user-profile-directory))
+
+    (let ((s (stat %profile-directory #f)))
+      ;; Attempt to create /…/profiles/per-user/$USER if needed.
+      (unless (and s (eq? 'directory (stat:type s)))
+        (catch 'system-error
+          (lambda ()
+            (mkdir-p %profile-directory))
+          (lambda args
+            ;; Often, we cannot create %PROFILE-DIRECTORY because its
+            ;; parent directory is root-owned and we're running
+            ;; unprivileged.
+            (format (current-error-port)
+                    (_ "error: while creating directory `~a': ~a~%")
+                    %profile-directory
+                    (strerror (system-error-errno args)))
+            (format (current-error-port)
+                    (_ "Please create the `~a' directory, with you as the owner.~%")
+                    %profile-directory)
+            (rtfm))))
+
+      ;; Bail out if it's not owned by the user.
+      (unless (or (not s) (= (stat:uid s) (getuid)))
+        (format (current-error-port)
+                (_ "error: directory `~a' is not owned by you~%")
+                %profile-directory)
+        (format (current-error-port)
+                (_ "Please change the owner of `~a' to user ~s.~%")
+                %profile-directory (or (getenv "USER")
+                                       (getenv "LOGNAME")
+                                       (getuid)))
+        (rtfm))))
+
+  (define (process-actions opts)
+    ;; Install packages from OPTS.
+
+    (define dry-run? (assoc-ref opts 'dry-run?))
+    (define profile  (assoc-ref opts 'profile))
+
+    (define (build-and-use-profile manifest)
+      (when (equal? profile %current-profile)
+        (ensure-default-profile))
+
+      (let* ((prof-drv (run-with-store (%store)
+                         (profile-derivation
+                          manifest
+                          #:hooks %default-profile-hooks)))
+             (prof     (derivation->output-path prof-drv)))
+        (show-what-to-build (%store) (list prof-drv)
+                            #:use-substitutes?
+                            (assoc-ref opts 'substitutes?)
+                            #:dry-run? dry-run?)
+
+        (cond
+         (dry-run? #t)
+         ((and (file-exists? profile)
+               (and=> (readlink* profile) (cut string=? prof <>)))
+          (format (current-error-port) (_ "nothing to be done~%")))
+         (else
+          (let* ((number (generation-number profile))
+
+                 ;; Always use NUMBER + 1 for the new profile,
+                 ;; possibly overwriting a "previous future
+                 ;; generation".
+                 (name   (generation-file-name profile
+                                               (+ 1 number))))
+            (and (build-derivations (%store) (list prof-drv))
+                 (let* ((entries (manifest-entries manifest))
+                        (count   (length entries)))
+                   (switch-symlinks name prof)
+                   (switch-symlinks profile name)
+                   (unless (string=? profile %current-profile)
+                     (register-gc-root (%store) name))
+                   (format #t (N_ "~a package in profile~%"
+                                  "~a packages in profile~%"
+                                  count)
+                           count)
+                   (display-search-paths entries profile))))))))
+
+    (let* ((manifest    (profile-manifest profile))
+           (install     (options->installable opts manifest))
+           (transaction (manifest-transaction (install install)))
+           (new         (manifest-perform-transaction
+                         manifest transaction)))
+      (show-manifest-transaction (%store) manifest transaction
+                                 #:dry-run? dry-run?)
+      (build-and-use-profile new)))
+
+  (let ((opts (parse-command-line args %options (list %default-options)
+                                  #:argument-handler handle-argument)))
+    (with-error-handling
+      (parameterize ((%store (open-connection)))
+        (set-build-options-from-command-line (%store) opts)
+
+        (parameterize ((%guile-for-build
+                        (package-derivation
+                         (%store)
+                         (canonical-package guile-2.0))))
+          (process-actions opts))))))
-- 
2.4.3

Re: Add guix install command

[Mathieu Lirzin]

Andy Wingo <wingo@igalia.com> writes:

> I think Guix's tooling is OK but it could be better.  [...]
> Attached is a patch to implement "guix install".  It just copies over
> functionality from guix package.  We could refactor more but I would
> start with this as it is; when things need changes is the time to
> refactor, at least for me.  What do you think? :)

I really like the idea of having sub commands which names are verbs like
in Git, otherwise I agree that these familiar names are easier to
remember than 'guix package' options. So I really welcome this patch! :)

> From 7f1ac0b748a40b0a093d20c27401f305ce6aec9f Mon Sep 17 00:00:00 2001
> From: Andy Wingo <wingo@igalia.com>
> Date: Wed, 5 Aug 2015 11:27:48 +0200
> Subject: [PATCH] Add guix install command
>
> * guix/scripts/install.scm: New file.
> * doc/guix.texi: Change guix package -i invocations to use guix install.
>   (Features): Add links to "Invoking guix install".
>   (Invoking guix install): New section.
>   (Invoking guix package): Link back to Invoking guix install.
[...]
> -*** New ‘guix edit’ and ‘guix size’ commands
> +*** New ‘guix edit’, ‘guix size’, and ‘guix install’ commands

These are "old" news for the already released 0.8.3. I think it's better
to add nothing yet and let Ludovic synthesize the NEWS before the next
release.

--
Mathieu Lirzin

Re: Add guix install command

[Alex Kost]

Andy Wingo (2015-08-05 12:36 +0300) wrote:

> Hi,
>
> I think Guix's tooling is OK but it could be better.  As a user -- and
> I'm really trying to be a user and not a developer :-) -- my main
> interactions with a Guix system are installing, searching, and
> upgrading.  Sometimes mucking about with profiles, sometimes more
> involved things, but usually installing, searching, and upgrading, in
> that order.
>
> So to me the guix package command is a bit overkill for my uses and I
> always forget which options are which (often typing "guix install" only
> to be told there is no such thing, likewise for search, and is it search
> with big -S or little -s?).  I spend a lot of my time with guix looking
> at the --help output (and I still don't know why "guix help package"
> doesn't give me anything useful).
>
> I know that guix package is definitely the core interface, and the one
> that Guix wants.  However I would like to plead for adding more
> special-purpose subset interfaces :)  They will make user life better.
>
> Attached is a patch to implement "guix install".  It just copies over
> functionality from guix package.  We could refactor more but I would
> start with this as it is; when things need changes is the time to
> refactor, at least for me.  What do you think? :)

I don't mind the new commands, but I think this patch is unacceptable
because of the huge code duplicating.  Sorry if it was sounded rude, I
just think that refactoring needs to be done instead of copying pieces
from (guix scripts package).

-- 
Alex

Re: Add guix install command

[Andy Wingo]

On Fri 07 Aug 2015 09:47, Alex Kost <alezost@gmail.com> writes:

> Andy Wingo (2015-08-05 12:36 +0300) wrote:
>
> I don't mind the new commands, but I think this patch is unacceptable
> because of the huge code duplicating.  Sorry if it was sounded rude

Better to just not be rude, please.  I know "this patch is unacceptable"
made me feel bad when I saw it.  I've been around the block a few times
so it's OK but if I were new to free software I would appreciate a
different way of saying this.  Just something to think about.

> I just think that refactoring needs to be done instead of copying
> pieces from (guix scripts package).

Will do, thanks for the feedback :)

Andy

Re: Add guix install command

[Ricardo Wurmus]

>> Attached is a patch to implement "guix install".  It just copies over
>> functionality from guix package.  We could refactor more but I would
>> start with this as it is; when things need changes is the time to
>> refactor, at least for me.  What do you think? :)
>
> I don't mind the new commands, but I think this patch is unacceptable
> because of the huge code duplicating.  Sorry if it was sounded rude, I

Would it be possible to implement this with stubs for “guix install” and
“guix search” that serve as mere aliases to “guix package -i” and “guix
package -s”?

I think it would be nice to have these commands as long as they are just
aliases and don’t duplicate code.

~~ Ricardo

Re: Add guix install command

[Mathieu Lirzin]

Alex Kost <alezost@gmail.com> writes:

> Andy Wingo (2015-08-05 12:36 +0300) wrote:
>[...]
>> Attached is a patch to implement "guix install".  It just copies over
>> functionality from guix package.  We could refactor more but I would
>> start with this as it is; when things need changes is the time to
>> refactor, at least for me.  What do you think? :)
[...]
> I just think that refactoring needs to be done instead of copying
> pieces from (guix scripts package).

AIUI doing a "good" refactoring job will imply a lot of code moving
because It means separating the interfaces from the functionalities.
IMO that could be left to next iterations.  However, IIUC this patch
could be lighter by using indirections to the 'guix-package' procedure
fornow instead of copying chunks of code.  Is that what you mean?

--
Mathieu Lirzin

Re: Add guix install command

[Andy Wingo]

On Fri 07 Aug 2015 10:48, Ricardo Wurmus <rekado@elephly.net> writes:

>>> Attached is a patch to implement "guix install".  It just copies over
>>> functionality from guix package.  We could refactor more but I would
>>> start with this as it is; when things need changes is the time to
>>> refactor, at least for me.  What do you think? :)
>>
>> I don't mind the new commands, but I think this patch is unacceptable
>> because of the huge code duplicating.  Sorry if it was sounded rude, I
>
> Would it be possible to implement this with stubs for “guix install” and
> “guix search” that serve as mere aliases to “guix package -i” and “guix
> package -s”?
>
> I think it would be nice to have these commands as long as they are just
> aliases and don’t duplicate code.

In the case of "guix install", yes.  However what would you show for
"guix install --help"?  What would error messages show: "guix package"
or "guix install"?  Would the user perceive it as a separate command or
would the fact that it is an alias be visible to the user?

I have a lot of opinions of course ;) but IMO for a user it's better for
it to present as a separate command.  Why?  Because understanding all of
"guix package" (or simply paging it back into human memory) is harder
than understanding all of "guix install".  Describing "guix install" is
easier than describing "guix package".

Also FWIW the equivalent of "guix package --install-from-expression foo"
is, as of this patch, "guix install --from-expression foo".  Reads nicer
to me but dunno, might be a point of conflict.

For search, I chose to default to a more terse format (--short rather
than --recutils).  Also the --recutils and --short options probably
don't make sense as arguments to "guix package", at least not named how
they are.

Basically it seems to me that "guix package" is doing too much as it
is.  Dunno how you see it though.  I am new here :)

Cheers,

Andy

Re: Add guix install command

[Thompson, David]

On Fri, Aug 7, 2015 at 8:01 AM, Andy Wingo <wingo@igalia.com> wrote:
> On Fri 07 Aug 2015 10:48, Ricardo Wurmus <rekado@elephly.net> writes:
>
>>>> Attached is a patch to implement "guix install".  It just copies over
>>>> functionality from guix package.  We could refactor more but I would
>>>> start with this as it is; when things need changes is the time to
>>>> refactor, at least for me.  What do you think? :)
>>>
>>> I don't mind the new commands, but I think this patch is unacceptable
>>> because of the huge code duplicating.  Sorry if it was sounded rude, I
>>
>> Would it be possible to implement this with stubs for “guix install” and
>> “guix search” that serve as mere aliases to “guix package -i” and “guix
>> package -s”?
>>
>> I think it would be nice to have these commands as long as they are just
>> aliases and don’t duplicate code.
>
> In the case of "guix install", yes.  However what would you show for
> "guix install --help"?  What would error messages show: "guix package"
> or "guix install"?  Would the user perceive it as a separate command or
> would the fact that it is an alias be visible to the user?

If we were to go the aliasing route, we could still make the --help
and --version flags show 'guix install' with a simple pattern match on
the arguments list.

> I have a lot of opinions of course ;) but IMO for a user it's better for
> it to present as a separate command.  Why?  Because understanding all of
> "guix package" (or simply paging it back into human memory) is harder
> than understanding all of "guix install".  Describing "guix install" is
> easier than describing "guix package".

I definitely see where you are coming from, and you're not the first
person to suggest something like this, but for some reason I'm just
not sure about it.  It's good in the sense that users coming from apt
and yum could just type the thing they think should work and it will
work.  The downside is that it leaks profile management into many
subcommands and users will still need to use another tool to roll back
generations, update, or remove packages ('guix package' lets you do it
all in a single transaction).  Managing profiles is but one of the
many things that Guix does, and every other tool encapsulates it's
full functionality under a single subcommand: import, system,
environment, gc, lint, etc.

> Also FWIW the equivalent of "guix package --install-from-expression foo"
> is, as of this patch, "guix install --from-expression foo".  Reads nicer
> to me but dunno, might be a point of conflict.

I would agree that it reads a bit nicer.

> For search, I chose to default to a more terse format (--short rather
> than --recutils).  Also the --recutils and --short options probably
> don't make sense as arguments to "guix package", at least not named how
> they are.
>
> Basically it seems to me that "guix package" is doing too much as it
> is.  Dunno how you see it though.  I am new here :)

I think we should wait to hear Ludovic's thoughts when he's back from
vacation since he designed the interface.  Thanks for starting the
discussion with this patch.

- Dave

Re: Add guix install command

[Andy Wingo]

Thanks for the comments.  Just a couple points, happy to wait for
Ludovic to get back.

On Fri 07 Aug 2015 14:22, "Thompson, David" <dthompson2@worcester.edu> writes:

>> In the case of "guix install", yes.  However what would you show for
>> "guix install --help"?  What would error messages show: "guix package"
>> or "guix install"?  Would the user perceive it as a separate command or
>> would the fact that it is an alias be visible to the user?
>
> If we were to go the aliasing route, we could still make the --help
> and --version flags show 'guix install' with a simple pattern match on
> the arguments list.

You would have to modify the set of arguments as well.  What it mean to
say e.g. "guix install --remove foo bar" ?  If it were supported as an
alias and all guix package options were there, "guix package --remove
foo bar" would remove foo and bar, but you might expect "guix install
--remove foo bar" to remove foo but install bar -- but even then "guix
install --remove" is nonsensical.

To me I see the advantage of guix install as "paving the cowpaths" --
making a common use case easy while still pointing to more powerful
tools.

> every other tool encapsulates it's full functionality under a single
> subcommand: import, system, environment, gc, lint, etc.

This is a very slight advantage from the maintainer POV but from the
user's POV it's a negative thing, I think.

"guix package" just does too much: for example try "guix package
--install foo --list-available".  It doesn't install foo at all, or even
try!

Andy

Re: Add guix install command

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3891 bytes --]

Hi,

As a new user myself, I think I'd like to add my own opinion.

When the subcommands are explicitly namespaced (as in "guix package -i
foo"), I find it easier to (1) understand and (2) look up usage
information. In my opinion, shoving many disparate actions (and thus,
options) into a single global namespace complicates matters greatly. It
puts more cognitive burden on the user. If you do that, then users have to
remember whether the word that comes after "guix" is a full-fledged
subcommand, or just a shortcut into one (and they also have to remember
whether there are any differences or limitations when using one versus the
other). If you really want a short alias for "guix package --install", you
can always create one yourself in exactly the way you want using a shell
alias, a shell function, or a wrapper script. It doesn't seem necessary, to
me, to complicate usage by adding alternative invocations by default. It id
better to provide a simple default and let the users customize it if they
want to.

In addition, I also think that an invocation like "guix install" would be
suboptimal because it wouldn't be immediately clear whether the invocation
will install packages or modify the system itself (like "guix system
reconfigure foo"). This is an example of how removing the namespacing might
complicate things.

You've mentioned apt and suggested that it does this the right way (apt-get
install pkg). I respectfully disagree. I think that, from a user
perspective, it's cleaner to have subcommands than it is to have one
command for installing (apt-get) and another for searching (apt-cache).
With apt, it may seem like you are invoking a single command, but you have
to remember which apt tool to use, which in the end isn't much different
than the way guix does it. But I'm glad guix uses subcommands instead of
separate commands, since I think that's cleaner, easier to remember, and
easier to look up information about.

I think keeping things simple makes a lot of sense, especially since you
can add your own convenience wrapper easily using shell aliases etc. Thanks
for listening to my opinion - Guix is great and I'm looking forward to
using it more and more!

Thank you,
Chris

On Fri, Aug 7, 2015, 05:36 Andy Wingo <wingo@igalia.com> wrote:

> Thanks for the comments.  Just a couple points, happy to wait for
> Ludovic to get back.
>
> On Fri 07 Aug 2015 14:22, "Thompson, David" <dthompson2@worcester.edu>
> writes:
>
> >> In the case of "guix install", yes.  However what would you show for
> >> "guix install --help"?  What would error messages show: "guix package"
> >> or "guix install"?  Would the user perceive it as a separate command or
> >> would the fact that it is an alias be visible to the user?
> >
> > If we were to go the aliasing route, we could still make the --help
> > and --version flags show 'guix install' with a simple pattern match on
> > the arguments list.
>
> You would have to modify the set of arguments as well.  What it mean to
> say e.g. "guix install --remove foo bar" ?  If it were supported as an
> alias and all guix package options were there, "guix package --remove
> foo bar" would remove foo and bar, but you might expect "guix install
> --remove foo bar" to remove foo but install bar -- but even then "guix
> install --remove" is nonsensical.
>
> To me I see the advantage of guix install as "paving the cowpaths" --
> making a common use case easy while still pointing to more powerful
> tools.
>
> > every other tool encapsulates it's full functionality under a single
> > subcommand: import, system, environment, gc, lint, etc.
>
> This is a very slight advantage from the maintainer POV but from the
> user's POV it's a negative thing, I think.
>
> "guix package" just does too much: for example try "guix package
> --install foo --list-available".  It doesn't install foo at all, or even
> try!
>
> Andy
>
>

[-- Attachment #2: Type: text/html, Size: 4704 bytes --]

Re: Add guix install command

[Alex Kost]

Andy Wingo (2015-08-07 11:45 +0300) wrote:

> On Fri 07 Aug 2015 09:47, Alex Kost <alezost@gmail.com> writes:
>
>> Andy Wingo (2015-08-05 12:36 +0300) wrote:
>>
>> I don't mind the new commands, but I think this patch is unacceptable
>> because of the huge code duplicating.  Sorry if it was sounded rude
>
> Better to just not be rude, please.  I know "this patch is unacceptable"
> made me feel bad when I saw it.  I've been around the block a few times
> so it's OK but if I were new to free software I would appreciate a
> different way of saying this.  Just something to think about.

I really didn't mean to be rude, sorry again.  I just couldn't find
the better words.

-- 
Alex

Re: Add guix install command

[Alex Kost]

Mathieu Lirzin (2015-08-07 13:08 +0300) wrote:

> Alex Kost <alezost@gmail.com> writes:
>
>> Andy Wingo (2015-08-05 12:36 +0300) wrote:
>>[...]
>>> Attached is a patch to implement "guix install".  It just copies over
>>> functionality from guix package.  We could refactor more but I would
>>> start with this as it is; when things need changes is the time to
>>> refactor, at least for me.  What do you think? :)
> [...]
>> I just think that refactoring needs to be done instead of copying
>> pieces from (guix scripts package).
>
> AIUI doing a "good" refactoring job will imply a lot of code moving
> because It means separating the interfaces from the functionalities.
> IMO that could be left to next iterations.  However, IIUC this patch
> could be lighter by using indirections to the 'guix-package' procedure
> fornow instead of copying chunks of code.  Is that what you mean?

No, as Andy pointed you can't just use 'guix-package' procedure for
several reasons.  My only concern is to avoid the code duplication.  I'm
afraid that postponing refactoring in practice may mean the code will
remain in this state for years.

-- 
Alex

Re: Add guix install command

[Ludovic Courtès]

Chris Marusich <cmmarusich@gmail.com> skribis:

> I think keeping things simple makes a lot of sense, especially since you
> can add your own convenience wrapper easily using shell aliases etc.

One could add a ‘guix-install’ alias, but not a ‘guix install’ alias,
though.

> Thanks for listening to my opinion - Guix is great and I'm looking
> forward to using it more and more!

Thanks for your feedback!

Ludo’.

Re: Add guix install command

[Ludovic Courtès]

Hi!

I sympathize with the idea that ‘guix package -i’ and co. can be
cumbersome to type and maybe non-obvious, so I would be happy to add
‘guix install’, ‘guix remove’, and ‘guix search’.  I would prefer to
document ‘guix package’ as the canonical interface though, for the
reasons David and Chris gave.

However, this should be gratis in maintenance costs IMO, which means no
code duplication and equivalent functionality.

Thus, that probably means making ‘guix install’ a strict alias for ‘guix
package -i’, with the oddities that you mentioned, Andy (one could run
‘guix install foo -r bar’ and so on.)

So, what about adding a simple alias mechanism for ‘run-guix-command’ in
(guix ui) and using it to define those three aliases?  ‘guix help’ and
similar would explicitly mark them as aliases.

Eventually, we could allow users to define aliases via
~/.config/guix/aliases, say.

Thoughts?

Thanks,
Ludo’.

Re: Add guix install command

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1869 bytes --]

Hi,

That sounds like it could be a reasonable compromise to me, as long as it's
clearly documented in the Texinfo and help text that it's an alias.
However, it seems to me that it would duplicate the well known features of
any shell (i.e. defining your own aliases or functions to make certain
frequently used commands easier to use), so in my opinion it's not
necessary and just complicates things ever so slightly.

Ultimately this is probably not a major issue, and I am sure I will be able
to use guix either way. However, I have seen one too many enormously
complex and confusing pieces of software, so I personally have an allergic
reaction to anything that unnecessarily introduces complexity, even a tiny
amount of it.

Best regards,
Chris

On Tue, Aug 18, 2015, 09:23 Ludovic Courtès <ludo@gnu.org> wrote:

> Hi!
>
> I sympathize with the idea that ‘guix package -i’ and co. can be
> cumbersome to type and maybe non-obvious, so I would be happy to add
> ‘guix install’, ‘guix remove’, and ‘guix search’.  I would prefer to
> document ‘guix package’ as the canonical interface though, for the
> reasons David and Chris gave.
>
> However, this should be gratis in maintenance costs IMO, which means no
> code duplication and equivalent functionality.
>
> Thus, that probably means making ‘guix install’ a strict alias for ‘guix
> package -i’, with the oddities that you mentioned, Andy (one could run
> ‘guix install foo -r bar’ and so on.)
>
> So, what about adding a simple alias mechanism for ‘run-guix-command’ in
> (guix ui) and using it to define those three aliases?  ‘guix help’ and
> similar would explicitly mark them as aliases.
>
> Eventually, we could allow users to define aliases via
> ~/.config/guix/aliases, say.
>
> Thoughts?
>
> Thanks,
> Ludo’.
>
>

[-- Attachment #2: Type: text/html, Size: 2217 bytes --]