From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bengt Richter Subject: Re: Guix System video review on YouTube Date: Mon, 27 Apr 2020 19:37:42 +0200 Message-ID: <20200427173742.GA4811@LionPure> References: <855dde2f-a7c7-d6e4-b649-a3bae60f99cb@web.de> <6222f23d-3e9e-5f47-f415-488bc18cbb1f@web.de> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:58148) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT7ho-0003lT-Du for guix-devel@gnu.org; Mon, 27 Apr 2020 13:38:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jT7hn-0007Vy-03 for guix-devel@gnu.org; Mon, 27 Apr 2020 13:38:07 -0400 Received: from imta-36.everyone.net ([216.200.145.36]:44364 helo=imta-38.everyone.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jT7hm-0007T8-Ce for guix-devel@gnu.org; Mon, 27 Apr 2020 13:38:06 -0400 Content-Disposition: inline In-Reply-To: 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-mx.org@gnu.org Sender: "Guix-devel" To: zimoun Cc: Guix-devel Hi zimoun, Jonathan, On +2020-04-27 14:44:08 +0200, zimoun wrote: > On Mon, 27 Apr 2020 at 12:11, Jonathan Brielmaier > wrote: > > > >> * While installing packages via `guix install` you can't scroll in the > > >> terminal, you always get reset to the bottom. > > > > > > I missed what it mean. Could you quickly extend a bit? > > > > $ echo "hello" > > hello > > $ guix install emacs > > > > Then while installing emacs, try to reach the hello. It will be tricky > > as every new output line from `guix install emacs` will reset you to the > > bottom of your terminal. That's annoying. > > Does not it depend on the terminal emulator? > Yes, I think this is an example of how answering the question "What code shall we modify/add to solve this usability annoyance?" can affect system architecture, positively or negatively. You could have guix fork the install into a thread that outputs to and scrolls the uppper half of the screen, while wrapping your terminal cli so it keeps to the bottom half, but I think that is a wrong solution. OTOH there could be a --progress=... option so you could end the line with '&' and continue your shell interaction. Simple options might direct output to another tty or a file, with \r...line...\r lines stripped until \r?\n, or pipe to whatever (could be a wayland client that makes a status line window on top and filters the stream for interesting progress items to present -- if that's available -- but guix doesn't need to know what's on the other end of that optional progress report pipe, so it. KISS, avoid needing to know :) Or with a terminal emulation app like tilix, it's easy to run several things in split or overlaid terminal windows, doing whatever. > > > >> * guix show/search does not show if a package is installed. > > > > > > Installed where? In which profile? > > > I am not sure that "installed" make sense at the level of "guix show/search". > > > > It definitely does. It could show packages installed to the profile, > > such coming from the config.scm etc. > > I am not using Guix System so I do not have config.scm. > > Well, you propose that to loop over all the user profiles (i.e., "guix > package --list-profiles) to check if it is installed in one of them, > right? > I am not convinced it is useful. > Create a new profile and install what I need is cheap so I do not see > why it could be useful to know if the package is already installed or > not. If it is, nothing to be done; if not it is installed where I need > it. > However, what is useful is to know if the item already exist or not in > the store, IMHO. > > When "guix install vim", for example the package 'tcsh' goes in the > store but is not considered "installed" by the profile say > '~/.guix-profile'. Therefore, does "guix show tcsh" display > 'installed' or 'not installed'? > > Because of the profiles -- and I am even not talking about grafts -- I > am not sure that "installed" make sense at the level of "guix > show/search". ;-) > There is too much corner cases, IMHO. > > > > >> * `guix search ... | less can be confusing at the beginning. > > > > > > There is room of improvements for "guix search". ;-) > > > > > > There is 3 behaviours > > > 1. return the N packages fitting the screen size (current: default) > > > 2. display all the list in PAGER (current: |less) > > > 3. display all the list in stdout (current: |cat) > > > > > > The feature request is: be able to configure which behaviour by > > > default for "guix search". Maybe via an environment variable. > > > (as discussed elsewhere by Ricardo and Tobias, if I understand correctly) > > > > > > > > > WDYT? > > > > To be honest I would like the search to behave more like `guix package > > -A`. Then we don't need this `less` thing. And we could add something > > like `guix search --expanded` which behaves like the current search. > > I agree. > There is room of improvement about "guix search". > > Some time ago, I also proposed to have something like: "--format" > (inspired by "git log --format=") > > guix search vim --format="%name %synopsis" > guix search vim --format="%name \n %license \n" > guix search crypto library --format=full > etc. > For alternative formatting, I like the convention used by lsblk and ps of specifying field/data names as -o,field,another,etc to select how and what to display. I'd guess there's some FLOSS code in lsblk that could be re-used by guix. > It should be also used by "guix show" and we could even imagine by > "guix package -A". > > Well, as one said: patches welcome. :-) > > > > > $ zypper search vim | wc -l > > 84 > > $ guix package -A vim | wc -l > > 22 > > $ guix search vim | less > > 828 lines and you have to search again in less because you are overwhelmed > > I do not know 'zypper', only 'aptitude' of Debian. :-) > > And there is a big difference between "guix search" and such tools: > the relevance scoring. > Well, "guix search" does not sort alphanumerically by name but sort by > relevance depending on the query. > > The order is not predictable. Sometimes we want to order by relevance > (for discoverability), sometimes not. Therefore, it should be possible > to order by any keys than the relevance (using alphanumerical > ordering) > > > > So I would propose an interface like: > > $ guix search vim > > | Name | Synopsis | Version | Outputs | > > +---------------+--------------------------------+----------+---------+ > > | vim | Text editor based on vi | 8.2.0411 | out | > > | vim-airline | ... > > [...] > > This is rather similar to debian dpkg -l '*vim*' output: (that's an ls '*vim*' kind of glob expr, BTW.) --8<---------------cut here---------------start------------->8--- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================================== un vim (no description available) un vim-athena (no description available) ii vim-common 2:8.1.0875-5 all Vi IMproved - Common files un vim-gnome (no description available) un vim-gtk (no description available) un vim-gtk3 (no description available) un vim-nox (no description available) ii vim-tiny 2:8.1.0875-5 amd64 Vi IMproved - enhanced vi editor - compact version --8<---------------cut here---------------end--------------->8--- you can obviously grep ^ii to see what's installed only, or grep -v ^un to keep the headers with the ii's > > The the search command would fulfill it's function by giving you an > > overview about the available options. > > I agree as explained above. :-) > Room of improvements for "guix search". :-) > > > > >> * Multi user package concept not clear (root as different packages then > > >> normal user). > > > > > > This is related to expectation about "installed", IMHO. > > > > Yes. But can be confusing for all the people coming from traditional > > package managers where root and user share the same packages. > > Yes shifting is always difficult. :-) > > > Cheers, > simon > -- Regards, Bengt Richter