Re: guix.el & multiple outputs
Alex Kost skribis: > Yes, you are right that defaults should be more user friendly :-) > I've made appropriate changes, so now the only difference a user will > see in the new version is that there are outputs (not packages) listed > in *Guix Package List* buffer. > > And to return to the previous variant, one may use (it is documented): > > (setq guix-package-list-type 'package) Perfect. > A modified patch is attached. OK to push! Ludo’.
Re: guix.el & multiple outputs
Ludovic Courtès (2014-09-21 23:37 +0400) wrote: > Alex Kost skribis: > >> Ludovic Courtès (2014-09-07 01:11 +0400) wrote: >> >>> Taylan Ulrich Bayirli/Kammer skribis: >>> By the way, it might be nice to have an option to list the secondary outputs of a package explicitly alongside the normal, as if it were just another package. >>> >>> Currently *Guix Package List* shows, for instance: >>> >>> gcc-toolchain4.9.1 out, debugdebug, outComplete GCC >>> tool chain for C/C++ development >>> >>> Are you suggesting that it should instead show it as two lines? >>> >>> gcc-toolchain4.9.1 out yes Complete GCC tool chain >>> for C/C++ development >>> gcc-toolchain4.9.1 debugyes Complete GCC tool chain >>> for C/C++ development >>> >>> I think I would prefer it. (One advantage is that it would allow users >>> to mark just one specific output, which is not currently possible.) > > [...] > >> As for the changes visible to a user: now it is possible to get a list >> of outputs with “(setq guix-package-list-type 'output)”. Should it be >> default? > > The list of outputs means there’s one line for each output, as in the > example above, right? Yes. > I would make it the default, yes. OK, I made it the default option. >> Another UI question: RET in “*Guix Package List*” buffer describes >> current package(s) in “*Guix Package Info*” buffer. Analogously, RET in >> “*Guix Output List*” buffer describes current output(s) in “*Guix Output >> Info*” buffer. However I think it's not very useful: “output-info” >> buffer is very similar to “package-info” but it contains only one output >> per package info. So I think it would be better to display a usual >> “package-info” buffer (with all available outputs for a package) when a >> user press RET in a list of outputs. [not a clear description, isn't it :-)] >> WDYT? > > I would prefer having just *Guix Package List* and *Guix Package Info* > (each listing all the outputs of packages), and not *Guix Output List* > and *Guix Output Info*. > > Would it be possible? Absolutely. [...] > I think this convinced me that it’s better to just have the > ‘package-info’ and the ‘package-list’ buffer do the right thing. The > added complexity above may be intimidating to users. Yes, you are right that defaults should be more user friendly :-) I've made appropriate changes, so now the only difference a user will see in the new version is that there are outputs (not packages) listed in *Guix Package List* buffer. And to return to the previous variant, one may use (it is documented): (setq guix-package-list-type 'package) A modified patch is attached. >From 794096c19f2c702ad75c6c598c9c8312e66f0c84 Mon Sep 17 00:00:00 2001 From: Alex Kost Date: Fri, 19 Sep 2014 09:57:36 +0400 Subject: [PATCH 2/2] emacs: Add support for displaying outputs. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Suggested by Taylan Ulrich Bayirli/Kammer and Ludovic Courtès. * emacs/guix-base.el (guix-param-titles): Add output titles. (guix-messages): Add output messages. (guix-get-package-id-and-output-by-output-id): New procedure. (guix-define-buffer-type): Add ':buffer-name' key. * emacs/guix-info.el: Add "output-info" buffer type. (guix-info-insert-methods): Add output methods. (guix-info-displayed-params): Add output params. (guix-output-info-insert-version, guix-output-info-insert-output): New procedures. * emacs/guix-list.el: Add "output-list" buffer type. (guix-list-column-format): Add output formats. (guix-list-column-value-methods): Add output methods. (guix-package-list-type): New variable. (guix-generation-list-show-packages): Use it. (guix-package-list-marking-check): Use 'guix-output-list-mode'. (guix-list-mark-package-upgrades): New procedure. (guix-package-list-mark-upgrades): Use it. (guix-list-execute-package-actions): New procedure. (guix-package-list-execute): Use it. (guix-list-describe-maybe): New procedure. (guix-list-describe): Use it. (guix-output-list-mark-install, guix-output-list-mark-delete, guix-output-list-mark-upgrade, guix-output-list-mark-upgrades, guix-output-list-execute, guix-output-list-make-action, guix-output-list-describe): New procedures. (guix-output-list-describe-type): New variable. * emacs/guix.el (guix-get-show-packages): Use 'guix-package-list-type'. * doc/emacs.texi (emacs Commands): Mention 'guix-package-list-type'. (emacs List buffer): Adjust accordingly. (emacs Info buffer): Likewise. (emacs Buffer Names): New node. (emacs Keymaps): Add keymaps for output buffers. --- doc/emacs.texi | 59 +++--- emacs/guix-base.el | 69 +++-- emacs/guix-info.el | 54 +++- emacs/guix-list.el | 176 ++--- emacs/guix.el | 12 ++-- 5 files changed, 329 insertions(+), 41 deletions(-) diff --git
Re: guix.el & multiple outputs
Alex Kost skribis: > Ludovic Courtès (2014-09-07 01:11 +0400) wrote: > >> Taylan Ulrich Bayirli/Kammer skribis: >> >>> By the way, it might be nice to have an option to list the secondary >>> outputs of a package explicitly alongside the normal, as if it were just >>> another package. >> >> Currently *Guix Package List* shows, for instance: >> >> gcc-toolchain4.9.1 out, debugdebug, outComplete GCC >> tool chain for C/C++ development >> >> Are you suggesting that it should instead show it as two lines? >> >> gcc-toolchain4.9.1 out yes Complete GCC tool chain for >> C/C++ development >> gcc-toolchain4.9.1 debugyes Complete GCC tool chain for >> C/C++ development >> >> I think I would prefer it. (One advantage is that it would allow users >> to mark just one specific output, which is not currently possible.) [...] > As for the changes visible to a user: now it is possible to get a list > of outputs with “(setq guix-package-list-type 'output)”. Should it be > default? The list of outputs means there’s one line for each output, as in the example above, right? I would make it the default, yes. > Another UI question: RET in “*Guix Package List*” buffer describes > current package(s) in “*Guix Package Info*” buffer. Analogously, RET in > “*Guix Output List*” buffer describes current output(s) in “*Guix Output > Info*” buffer. However I think it's not very useful: “output-info” > buffer is very similar to “package-info” but it contains only one output > per package info. So I think it would be better to display a usual > “package-info” buffer (with all available outputs for a package) when a > user press RET in a list of outputs. [not a clear description, isn't it :-)] > WDYT? I would prefer having just *Guix Package List* and *Guix Package Info* (each listing all the outputs of packages), and not *Guix Output List* and *Guix Output Info*. Would it be possible? > From 8154b7193e3dac02447d5f7096b92fb4b9d65ed0 Mon Sep 17 00:00:00 2001 > From: Alex Kost > Date: Wed, 17 Sep 2014 17:52:08 +0400 > Subject: [PATCH 1/3] emacs: Use general functions instead of generated ones. > > * emacs/guix-base.el: Add and use general functions instead of > specialized functions generated by 'guix-define-buffer-type' macro. > (guix-buffer-type, guix-entry-type): New variables. > (guix-set-vars): Add new variables. > (guix-get-show-entries, guix-show-entries, guix-set-buffer) > (guix-history-call, guix-make-history-item) > (guix-get-params-for-receiving, guix-revert-buffer) > (guix-redisplay-buffer): New functions. > (guix-define-buffer-type): Do not generate specialized functions. > * emacs/guix-info.el (guix-package-info-insert-full-names): Use > 'guix-get-show-entries'. > (guix-generation-info-insert-number): Likewise. > * emacs/guix-list.el (guix-list-describe): New function. > (guix-list-define-entry-type): Do not generate specialized one. > (guix-generation-list-show-packages): Use 'guix-get-show-entries'. > * emacs/guix.el (guix-show-generations-function): Remove. > (guix-get-show-packages): Use new functions. > (guix-get-show-generations): Likewise. I trust you here. :-) > From d3fbccfd8a86d6b96f77f8993e88df8fe755e15f Mon Sep 17 00:00:00 2001 > From: Alex Kost > Date: Fri, 19 Sep 2014 09:57:36 +0400 > Subject: [PATCH 3/3] emacs: Add support for displaying outputs. > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Suggested by Taylan Ulrich Bayirli/Kammer and Ludovic Courtès. > > * emacs/guix-base.el (guix-param-titles): Add output titles. > (guix-messages): Add output messages. > (guix-get-package-id-and-output-by-output-id): New procedure. > * emacs/guix-info.el: Add "output-info" buffer type. > (guix-info-insert-methods): Add output methods. > (guix-info-displayed-params): Add output params. > (guix-output-info-insert-version, guix-output-info-insert-output): New > procedures. > * emacs/guix-list.el: Add "output-list" buffer type. > (guix-list-column-format): Add output formats. > (guix-list-column-value-methods): Add output methods. > (guix-package-list-type): New variable. > (guix-generation-list-show-packages): Use it. > (guix-package-list-marking-check): Use 'guix-output-list-mode'. > (guix-list-mark-package-upgrades): New procedure. > (guix-package-list-mark-upgrades): Use it. > (guix-list-execute-package-actions): New procedure. > (guix-package-list-execute): Use it. > (guix-output-list-mark-install, guix-output-list-mark-delete, > guix-output-list-mark-upgrade, guix-output-list-mark-upgrades, > guix-output-list-execute, guix-output-list-make-action): New procedures. > * emacs/guix.el (guix-get-show-packages): Use 'guix-package-list-type'. > * doc/emacs.texi (emacs Commands): Mention 'guix-package-list-type'. > (emacs List buffer): Describe "output-list". > (emacs Info buffer): Describe "output-info". > (emacs Buffe
Re: guix.el & multiple outputs
Ludovic Courtès (2014-09-07 01:11 +0400) wrote: > Taylan Ulrich Bayirli/Kammer skribis: > >> By the way, it might be nice to have an option to list the secondary >> outputs of a package explicitly alongside the normal, as if it were just >> another package. > > Currently *Guix Package List* shows, for instance: > > gcc-toolchain4.9.1 out, debugdebug, outComplete GCC > tool chain for C/C++ development > > Are you suggesting that it should instead show it as two lines? > > gcc-toolchain4.9.1 out yes Complete GCC tool chain for > C/C++ development > gcc-toolchain4.9.1 debugyes Complete GCC tool chain for > C/C++ development > > I think I would prefer it. (One advantage is that it would allow users > to mark just one specific output, which is not currently possible.) Hello, I have made some changes to make that possible. Also I would like to push 2 more commits (the patches attached) with huge but internal changes. “guix-main.scm” is mostly rewritten (so the commit message is big and ugly). Now it looks purely functional for me (I finally removed ‘set-current-manifest-maybe!’). As for the changes visible to a user: now it is possible to get a list of outputs with “(setq guix-package-list-type 'output)”. Should it be default? Another UI question: RET in “*Guix Package List*” buffer describes current package(s) in “*Guix Package Info*” buffer. Analogously, RET in “*Guix Output List*” buffer describes current output(s) in “*Guix Output Info*” buffer. However I think it's not very useful: “output-info” buffer is very similar to “package-info” but it contains only one output per package info. So I think it would be better to display a usual “package-info” buffer (with all available outputs for a package) when a user press RET in a list of outputs. [not a clear description, isn't it :-)] WDYT? As always I'm not sure in the quality of the commit messages. Thanks for your patience :) >From 8154b7193e3dac02447d5f7096b92fb4b9d65ed0 Mon Sep 17 00:00:00 2001 From: Alex Kost Date: Wed, 17 Sep 2014 17:52:08 +0400 Subject: [PATCH 1/3] emacs: Use general functions instead of generated ones. * emacs/guix-base.el: Add and use general functions instead of specialized functions generated by 'guix-define-buffer-type' macro. (guix-buffer-type, guix-entry-type): New variables. (guix-set-vars): Add new variables. (guix-get-show-entries, guix-show-entries, guix-set-buffer) (guix-history-call, guix-make-history-item) (guix-get-params-for-receiving, guix-revert-buffer) (guix-redisplay-buffer): New functions. (guix-define-buffer-type): Do not generate specialized functions. * emacs/guix-info.el (guix-package-info-insert-full-names): Use 'guix-get-show-entries'. (guix-generation-info-insert-number): Likewise. * emacs/guix-list.el (guix-list-describe): New function. (guix-list-define-entry-type): Do not generate specialized one. (guix-generation-list-show-packages): Use 'guix-get-show-entries'. * emacs/guix.el (guix-show-generations-function): Remove. (guix-get-show-packages): Use new functions. (guix-get-show-generations): Likewise. --- emacs/guix-base.el | 292 - emacs/guix-info.el | 9 +- emacs/guix-list.el | 42 emacs/guix.el | 38 +++ 4 files changed, 198 insertions(+), 183 deletions(-) diff --git a/emacs/guix-base.el b/emacs/guix-base.el index 563df49..d4ac643 100644 --- a/emacs/guix-base.el +++ b/emacs/guix-base.el @@ -1,4 +1,4 @@ -;;; guix-base.el --- Common definitions +;;; guix-base.el --- Common definitions -*- lexical-binding: t -*- ;; Copyright © 2014 Alex Kost @@ -179,6 +179,14 @@ PARAM is a name of the entry parameter. VAL is a value of this parameter.") (put 'guix-entries 'permanent-local t) +(defvar-local guix-buffer-type nil + "Type of the current buffer.") +(put 'guix-buffer-type 'permanent-local t) + +(defvar-local guix-entry-type nil + "Type of the current entry.") +(put 'guix-entry-type 'permanent-local t) + (defvar-local guix-search-type nil "Type of the current search.") (put 'guix-search-type 'permanent-local t) @@ -187,42 +195,32 @@ VAL is a value of this parameter.") "Values of the current search.") (put 'guix-search-vals 'permanent-local t) -(defsubst guix-set-vars (entries search-type search-vals) - (setq guix-entries entries +(defsubst guix-set-vars (entries buffer-type entry-type + search-type search-vals) + (setq guix-entries entries +guix-buffer-type buffer-type +guix-entry-type entry-type guix-search-type search-type guix-search-vals search-vals)) -(defmacro guix-define-buffer-type (buf-type entry-type &rest args) - "Define common stuff for BUF-TYPE buffers for displaying entries. +(defun guix-get-symbol (postfix buffer-type &optional entry-type) + (intern (concat "guix-" + (when entry-type +
Re: guix.el & multiple outputs
Taylan Ulrich Bayirli/Kammer skribis:
> In that case, let me just mention a concrete annoyance I had which could
> be fixed on the UI side: I find it useful to keep a plain text list of
> all installed packages, in a format that can also be fed back in. So
> far I used "guix package -I | awk '{print $1}'", but that doesn't handle
> outputs. A little AWK hackery could do it, but parsing that output is
> probably wrong to begin with. Maybe a --machine-readable flag could be
> added, which would ideally list alternate outputs in the foo:bar format
> so they can directly be fed back in.
Right. I think we could change ‘guix package’ to display one line per
output, similar to what I suggested for guix.el.
Thanks,
Ludo’.
Re: guix.el & multiple outputs
Ludovic Courtès (2014-09-07 01:11 +0400) wrote:
> Taylan Ulrich Bayirli/Kammer skribis:
>
>> By the way, it might be nice to have an option to list the secondary
>> outputs of a package explicitly alongside the normal, as if it were just
>> another package.
>
> Currently *Guix Package List* shows, for instance:
>
> gcc-toolchain4.9.1 out, debugdebug, outComplete GCC
> tool chain for C/C++ development
>
> Are you suggesting that it should instead show it as two lines?
>
> gcc-toolchain4.9.1 out yes Complete GCC tool chain for
> C/C++ development
> gcc-toolchain4.9.1 debugyes Complete GCC tool chain for
> C/C++ development
>
> I think I would prefer it. (One advantage is that it would allow users
> to mark just one specific output, which is not currently possible.)
[...]
OK, I think I can add support for such list of outputs and there may be
a variable for a user to choose what variant ("package list" or "output
list") he prefers.
I hope I will implement it soon, but I also need to improve the code for
getting information about packages (in “guix-main.scm”). I'm thinking
hard on it :)
Re: guix.el & multiple outputs
l...@gnu.org (Ludovic Courtès) writes:
> Are you suggesting that it should instead show it as two lines?
>
> gcc-toolchain4.9.1 out yes Complete GCC tool chain for
> C/C++ development
> gcc-toolchain4.9.1 debugyes Complete GCC tool chain for
> C/C++ development
>
> I think I would prefer it. (One advantage is that it would allow users
> to mark just one specific output, which is not currently possible.)
Indeed, it lifts the whole need for separate key-bindings to choose a
non-standard output. Can't think of any downsides either; maybe just
making the list longer.
> Conceptually, this is similar to the distinction between “binary”
> packages and “source” packages in distros like Debian.
>
> Technically, the main reason why things are this way is that in most
> cases it’s not possible to have separate build processes (and thus
> separate objects) producing the various outputs, in part
> because byproducts contain hard-coded file names, which makes them
> non-relocatable.
>
> An obvious example is the “debug” output. Another is packages that
> produce both shared libraries and programs linked against those libs:
> what shared lib would appear in the RUNPATH of the executables?
Thanks for the explanation. :)
So as I understand it, while it would be possible --in an "everything is
possible" sense-- to change the system in such a way that separate
s would use the same build process, the effort/benefit ratio is
too bad.
In that case, let me just mention a concrete annoyance I had which could
be fixed on the UI side: I find it useful to keep a plain text list of
all installed packages, in a format that can also be fed back in. So
far I used "guix package -I | awk '{print $1}'", but that doesn't handle
outputs. A little AWK hackery could do it, but parsing that output is
probably wrong to begin with. Maybe a --machine-readable flag could be
added, which would ideally list alternate outputs in the foo:bar format
so they can directly be fed back in.
Taylan
guix.el & multiple outputs
Taylan Ulrich Bayirli/Kammer skribis: > By the way, it might be nice to have an option to list the secondary > outputs of a package explicitly alongside the normal, as if it were just > another package. Currently *Guix Package List* shows, for instance: gcc-toolchain4.9.1 out, debugdebug, outComplete GCC tool chain for C/C++ development Are you suggesting that it should instead show it as two lines? gcc-toolchain4.9.1 out yes Complete GCC tool chain for C/C++ development gcc-toolchain4.9.1 debugyes Complete GCC tool chain for C/C++ development I think I would prefer it. (One advantage is that it would allow users to mark just one specific output, which is not currently possible.) > So far the concept of outputs and how they're usually hidden from me has > only caused me (minor) irritations, and I don't really understand why we > can't just make them separate packages, but I'm ignorant on most Guix > internals so might just not be "getting" it. Conceptually, this is similar to the distinction between “binary” packages and “source” packages in distros like Debian. Technically, the main reason why things are this way is that in most cases it’s not possible to have separate build processes (and thus separate objects) producing the various outputs, in part because byproducts contain hard-coded file names, which makes them non-relocatable. An obvious example is the “debug” output. Another is packages that produce both shared libraries and programs linked against those libs: what shared lib would appear in the RUNPATH of the executables? HTH, Ludo’.
