[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix System video review on YouTube
From: |
Bengt Richter |
Subject: |
Re: Guix System video review on YouTube |
Date: |
Mon, 27 Apr 2020 19:37:42 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
Hi zimoun, Jonathan,
On +2020-04-27 14:44:08 +0200, zimoun wrote:
> On Mon, 27 Apr 2020 at 12:11, Jonathan Brielmaier
> <address@hidden> 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
Re: Guix System video review on YouTube, Efraim Flashner, 2020/04/27
Re: Guix System video review on YouTube, Danny Milosavljevic, 2020/04/27