Re: Guix System video review on YouTube

[Bengt Richter <bokr@bokr.com>]

Hi zimoun, Jonathan,

On +2020-04-27 14:44:08 +0200, zimoun wrote:
> On Mon, 27 Apr 2020 at 12:11, Jonathan Brielmaier
> <jonathan.brielmaier@web.de> 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            <none>       <none>       (no description available)
un  vim-athena     <none>       <none>       (no description available)
ii  vim-common     2:8.1.0875-5 all          Vi IMproved - Common files
un  vim-gnome      <none>       <none>       (no description available)
un  vim-gtk        <none>       <none>       (no description available)
un  vim-gtk3       <none>       <none>       (no description available)
un  vim-nox        <none>       <none>       (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