Guix support in Helm System Packages?

[Ambrevar]

I'm the current maintainer of Helm System Packages, a Helm-powered package manager which supports pacman, portage, dpkg (all Debian-based distributions) and xbps (Void Linux). It also runs over the network via TRAMP!

I was thinking of adding support for Guix but since there is an obvious overlap with guix.el I thought it would be worth discussing the features first.

guix-all-available-packages already provides most of the features of Helm System Packages. Combine it with helm-occur and you get a similar browsing experience. The main missing feature provided by Helm System Packages is the ability to mark the results of a search.

Thus I would suggest the following: helm-system-packages for Guix would simply switch to the *Guix Packages:... buffer and run a Helm-occur-like session where the action is to mark the packages. The downside is that it would not work over the network.

Otherwise I could just go ahead and re-implement an independent cache of the list of packages.

Thoughts?

[alezost]

guix-all-available-packages already provides most of the features of Helm System Packages.

Unfortunately, this command is not very useful: it is so slow that it may even fail on weaker machines. The problem is: Emacs-Guix uses Geiser to get package data from the Guile side; and Geiser (or rather some Emacs facilities that Geiser uses under the hood; probably tq.el library) is very very slow in returning big chunks of data. So I think using other package commands that display not-so-much packages is more preferable.

The main missing feature provided by Helm System Packages is the ability to mark the results of a search.

Hm, as for me, this is not a missing feature, as when I need to search for packages I just use the package search commands (such as guix-packages-by-name or guix-search-by-regexp). But implementing something similar wouldn't be hard, as bui.el (used by Emacs-Guix) already provides "filters" for the current list that are similar to the search you mean (there are even f f and f d key bindings to enable/disable filters, but they do nothing currently).

Thus I would suggest the following: helm-system-packages for Guix would simply switch to the *Guix Packages:... buffer and run a Helm-occur-like session where the action is the mark the packages. The downside is that it would not work over the network.

OK, I agree. I mean I know nothing about Helm-occur-like sessions and I don't know what kind of work over the network you mean, but if I understand correctly, you suggest some changes on the "Helm System Packages" side, right? If so, please do what you think is appropriate :-)

After all, this is a great initiative, thank you! What is needed from my side? (sorry, if I didn't understand something you write)

[Ambrevar]

So I think using other package commands that display not-so-much packages is more preferable.

What do you use to list non-installed packages?

Filters don't exactly cover the user-experience provided by Helm: a "live" search, that is, a list that gets refreshed as you type. This is, in my opinion, tremendously better than static filters.

What I meant with the network capability is that if you run helm-system-packages from a remote file / dired / eshell session, it will show the list of packages of the remote system and all actions will act onto that system. This effectively rids the user of ssh-ing into the machine and running some clumsy commandline commands to manage packages.

It would be nice to be able to run guix.el over the network. Does it have TRAMP support? Do you use process-file in you Elisp code?

I think I'll just go ahead with an independent Helm System Packages support, it's not much code I believe and it can only make for a healthy competition fruitful of good ideas! :)

[alezost]

What do you use to list non-installed packages?

I never have a need to list all the packages. Most of the times I use guix-packages-by-name and guix-search-by-name.

Filters don't exactly cover the user-experience provided by Helm: a "live" search, that is, a list that gets refreshed as you type. This is, in my opinion, tremendously better than static filters.

I see, I mean it is not my use-case, but I understand that it may convenient for other people.

What I meant with the network capability is that if you run helm-system-packages from a remote file / dired / eshell session, it will show the list of packages of the remote system and all actions will act onto that system. This effectively rids the user of ssh-ing into the machine and running some clumsy commandline commands to manage packages.

Ah, OK. I personally don't need this network support, and since nobody provided a patch for it, it is not supported by emacs-guix.

It would be nice to be able to run guix.el over the network. Does it have TRAMP support? Do you use process-file in you Elisp code?

No, emacs-guix doesn't have any sign of TRAMP or process-file.

I think I'll just go ahead with an independent Helm System Packages support, it's not much code I believe and it can only make for a healthy competition fruitful of good ideas! :)

I agree! I would do the same: I almost always was unsatisfied with other packages, so I often end up writing my own code :-)

If you'll have questions on guix or emacs-guix, please ask here or at help-guix@gnu.org.

[Ambrevar]

I've just committed some initial Guix support for Helm System Packages.

Highlights:

• Helm "live" search of all packages.
• Install / Uninstall a bunch of packages at once.
• Explore dependencies.
• Navigate the package files with Helm.
• TRAMP support (it should work over the network).

I've implemented a stupid cache system: dump guix package --search=. to a file. It's stupid but good enough for most cases.

For now I don't rely on guix.el at all, although I must confess it would allow many more features and a much cleaner implementation.

The main issue at the moment is for dependency listing: I use the output of guix package --search=. which contains the version numbers. Sadly, the version numbers can contain - which makes it difficult (impossible?) to parse. For instance:

> guix package --show=ncdu | recsel -R dependencies
ncurses-6.0-20170930

I seems to me that only a proper Guile query can fetch the dependencies without version numbers. Thoughts?

Another feature I miss: Is it possible to get the list of reverse dependencies? (That is, the packages that require the selected package.)

[alezost]

I've just committed some initial Guix support for Helm System Packages.

Wow, you are fast!

Highlights:

Helm "live" search of all packages.
Install / Uninstall a bunch of packages at once.
Explore dependencies.
Navigate the package files with Helm.
TRAMP support (it should work over the network).

Great! I think you should post the announcement on guix-help mailing list.

The main issue at the moment is for dependency listing: I use the output of guix package --search=. which contains the version numbers. Sadly, the version numbers can contain - which makes it difficult (impossible?) to parse. For instance:

> guix package --show=ncdu | recsel -R dependencies
ncurses-6.0-20170930

Oh, I see, yeah, it's a problem, I can't invent an appropriate regexp to split name and version.

It seems to me that only a proper Guile query can fetch the dependencies without version numbers. Thoughts?

Hm, well, if you have a wish to make a "Guile side" for your package, then sure it would be possible. But maybe a solution is to report at bug-guix@gnu.org telling that it would be good to use @ character to separate names and versions there.

Another feature I miss: Is it possible to get the list of reverse dependencies? (That is, the packages that require the selected package.)

Oh, it would be great indeed! I think there is no such kind of feature currently, but I'm not completely sure as I have not followed Guix development for about a year.

[Ambrevar]

Thank you very much for your feedback!

[Ambrevar]

It turns out that guix can display reverse dependencies:

guix refresh --list-dependent PACKAGES

[alezost]

Oh, great, I also should add some command to display these package dependents, thank you for the idea!

[Ambrevar]

The new version separator has been merged upstream.