emacs-helm / helm-system-packages

A Helm interface to the package manager of your operating system

Helm System Packages

This package is no more maintained and not fully working.

Introduction

Helm System Packages is an Emacs-based interface to the package manager of your operating system and remote systems as well.

Emacs’ knowledge is not required: see the stand-alone folder for a version targeted at non-Emacs users. Run the script and everything should be self-explanatory. If not then it’s a bug, please report it.

Start helm-system-packages to list all available packages (with installed packages as well as dependencies displayed in their own respective face). Fuzzy-search, mark and execute the desired action over any selections of packages:

• Install.
• Uninstall.
• Display packages details (in Org Mode!) or insert details at point.
• Find files owned by packages.
• And much more, including performing all the above over the network!

Helm System Packages provides a uniform interface over the following package managers:

• brew (macOS)
• dnf
• dpkg (apt & friends)
• guix
• pacman
• portage (emerge & friends)
• xbps
• And (hopefully) more to come! Contributions are welcome.

Some package managers come with their specific actions and even specific Helm sources, e.g. Portage’s USE flags.

Usage

There is only one entry point: helm-system-packages.

Use the persistent action to view the details of the marked packages.

Most actions can be called with a prefix argument to insert the result at point.

If started from a remote TRAMP buffer (e.g. dired, Eshell or just any remote file), helm-system-packages automatically switches to the packages of the remote system. The remote package manager can be different from the local one.

Maintenance & other operations

Helm System Packages only works over lists of packages. It does not feature any maintenance-related operations such as cleaning the cache or synchronizing the database.

system-packages is an Emacs package providing Emacs with universal commands for such operations. It is unrelated to Helm System Packages but both work well together.

Privileges

Transactions such as installing and removing packages are run via the `sudo` command in Eshell. If you’d like to cache the password for, say, an hour, you can configure Eshell to use its own version of sudo via TRAMP:

(require 'em-tramp)
(setq password-cache t)
(setq password-cache-expiry 3600)

Motivation

Most of the package managers GUIs out there do not provide much efficiency over their commandline counterparts.

The commandline workflow is centered around a cumbersome try-repeat loop:

1. Search for local packages.
2. Package missing? Search for remote packages.
3. List is too long? Pipe through a pager.
4. (Un)install the desired package by writing the searched package names again.

With Helm all those actions get factored into one. Helm sessions can also be resumed.

Screencasts

• Display information of multiple packages in an Org buffer, resume the search and finally install.

  

• Use Helm to find files of multiple packages across different sources.

  

• Use Helm to explore the graph of the (reverse) dependencies.

  

Development

WARNING: The programming interface is still under development and is prone to change.

Each module is rather straightforward, it only needs to define the following:

• A helm-system-packages-FOO function that starts a Helm session.
• An interactive helm-system-packages-FOO-refresh function to refresh the package list either manually or after transactions.

The helm-system-packages.el file provides some helper functions for Helm actions.

Roadmap

Strengthen the interface with structures

Factor all “info” actions?

We can add Org subsections for files, dependencies, etc. Those sections should be folded by default.

We probably still need specific “info” actions to insert at point.

Use bindings reflecting helm-list-elisp-packages

[#A] Port factorization to dpkg, portage

[#A] Port TRAMP support to brew

Add option to display multiline candidates for long descriptions.

With filtering, the displayed condidates won’t include those above the candidate limit

Can we include as many filtered candidates as possible?

References

• https://wiki.voidlinux.org/Rosetta_stone
• https://wiki.archlinux.org/index.php/Pacman/Rosetta
• https://github.com/jabranham/system-packages

helm-system-packages's Issues

Use trizen/yaourt etc in arch

Hi,
How do i go about using trizen? It uses the same structure/commands as pacman but allows for aur support. (it doesnt require running as root however)

Thanks

Using Eshell with dpkg noninteractive mode

Hi, thank you for the wonderful package!
It is possible to disable interactive prompts of dpkg with the following command:
sudo DEBIAN_FRONTEND=noninteractive apt-get -q install postfix
I tried it in eshell and it worked fine. If you don't want to disable interactive mode of dpkg by default, there is a possibility to add an option for running dpkg non-interactively in eshell. I can create a PR, if you are interested in this feature.

Show all possible candidates after filtering

By default, helm-system-packages-candidate-limit is 1000.
Let's consider we have more than 1000 packages in the database.

If we disable the display of, say, uninstalled packages (M-N by default), it leaves room for more packages of the other categories to be displayed.
Sadly, the list won't be displayed unless a pattern is entered.

This issue makes it impossible to list all packages of specific categories.

The problem essentially lies in that Helm System Packages makes use of buffers and not lists.
I'm not sure how to solve that. @thierryvolpiatto?

Lacking abstraction

I've just found your blog and this package. I was excited. When I saw there was no support for dnf I started writing one starting from the support for dpkg. Then I realized that it was a lot of code to duplicate from dpkg even though I was expecting to mostly only implement a list of strings of command line arguments (in the same way as https://gitlab.com/jabranham/system-packages/).

Why is there so much stuff to implement? Is there any abstraction missing? Why isn't helm-system-packages depending on system-packages?

dpkg filters seem broken

Installed packages are no more colorized.
Commands M-I have no effect, hitting M-N end up with an empty buffer and next calls to helm-system-packages remain with an empty buffer until emacs is restarted.

"Waiting for process to die" and crashes when typing quickly on Gentoo

I'm getting Waiting for process to die... done in the minibuffer whenever I type a character within helm-system-packages on Gentoo (w/Portage), and when I type multiple characters in relatively quick succession (maybe within a second), the Helm buffer closes with no message. There isn't anything particularly nonstandard about my setup except syncing from git (eix works normally, etc.).

I couldn't find anything that might be causing this in my (admittedly cursory) overview of the source. As far as I can tell, helm-system-packages-refresh is only run at initialization and after commands are executed, and regardless runs without error when invoked manually.

Do you have any advice as to why this might be happening?

Remove default-directory prefix when running find-files on remote

Mentioned in #15:

Find files works fine on the local machine, but on the remote one the current
directory is prepending to the paths
e.g. /ssh:user@host:/home/user//usr/bin/etc. Ideally we need to strip
/home/user from the path.

It comes from the compatibility change with helm-ff--create-tramp-name for Emacs<26, but I'm not sure what's the ideal way to fix it.

@@ -383,15 +383,7 @@ Otherwise display in `helm-system-packages-buffer'."
   "Prefix FILE with path to remote connection.
 If local, return FILE unmodified."
   (if (tramp-tramp-file-p default-directory)
-      (let ((v (tramp-dissect-file-name default-directory)))
-        (tramp-make-tramp-file-name
-         (tramp-file-name-method v)
-         (tramp-file-name-user v)
-         (tramp-file-name-domain v)
-         (tramp-file-name-host v)
-         (tramp-file-name-port v)
-         file
-         (tramp-file-name-hop v)))
+      (helm-ff--create-tramp-name (concat default-directory file))
     file))

Before the patch, it used to work for Emacs 26 but not on Emacs<=25. With the patch, the default-directory file path is now used in the result, while we only want the default-directory protocol + user + host + etc., which we prepent to the file. @thierryvolpiatto?

On Void, `helm-system-packages` asks about missing apt dependencies

When I run helm-system-packages in Emacs on my Void machine, I get the message:

Dependencies are missing (apt-get, apt-cache, apt-mark), please install them

I don't see anything in the instructions about specially configuring the system to know that it's Void.

I also tried (require helm-system-packages-xbps) but that only give me one additional command helm-system-packages-xbps-refresh, which seems to work, but does not give me an interface to system packages.

Obsolete v1.10.2 under ArchLinux

As for today, guix provided v1.10.2 release is buggy under ArchLinux.
Installing from melpa (non stable, so latest commit) fixes the problem.

Persistent action is useless with org buffer folded

When hitting C-j on "git" package for example, only top node (*git) is shown making persistent action useless.
Perhaps using org-cycle in helm-system-packages-show-information would fix problem.
But I wonder why you are using org-mode in there when there is only one node, is it really useful ?

Stopped working

Hi,

helm-system-pacakges seem's to have broken, greeted with the following error

helm-fuzzy-highlight-matches: Symbol’s function definition is void: helm-mode--in-file-completion-p

Thanks

Use helm-source to define sources

Hello @Ambrevar you should now have access to helm-gentoo.
A first fix would be to define sources with helm-build-* macros.
Let me know if you can't push your changes.
Thanks.

Generic package: helm-portage and helm-package-manager

The current code deals with portage, not with the Gentoo specifics, so I think we should rename this package to helm-portage, a name which would make more sense on portage-based distributions that are not Gentoo.

More generally, maybe we should anticipate the growth of this package regarding other package managers.
I'd like to add support for Arch Linux' pacman in particular.
In that case, I suggest we rename the repo/project to helm-package-manager, while individual files would be named after their respective package manager, e.g. helm-pacman, helm-portage, etc.

What do you think?
@thierryvolpiatto

Find files in packages

Currently the "Find files" action only outputs the files in a buffer.
It would be much more useful to chain the action with another Helm session in which we could choose which files to "find".

This would be similar to what is currently done for URL:

    (browse-url (helm-comp-read "URL: " urls :must-match t))))))

Is there such a Helm interface that can take an arbitrary list of files as argument?
I'd like to have the actions of Helm Find Files in that session.

@thierryvolpiatto?

Discrepancy between helm-system-packages' "portage" and system-packages' "emerge"

I've got system-packages working relatively fine for Gentoo's Portage despite the fact that some of the commands defined for Emerge be default are (as I suspect) incorrect, and one could probably surmise that they were pulled from the Arch Wiki's Rosetta Stone and thus had something lost in translation. I'm not too confident about my understanding of Gentoo's emerge myself, which is why I haven't said anything. Notwithstanding, it's really no bother since that's easy to fix and doesn't really affect system-packages at a fundamental level.

Trying to execute helm-system-packages, though, in this state doesn't work. I get hit with the message "No such file or directory, helm-system-packages-emerge". Well, being the humple layman that I am, I'm not too fluent in elisp, nor do I really care to be, but that doesn't mean I can't navigate to the package directory and see that while there isn't a package named "helm-system-packages-emerge", there is a "helm-system-packages-portage". My first instinct was to just take the list of emerge commands defined in system-packages-supported-package-managers and ascribe them to portage instead, but that didn't really changes much.

I've never done this before, so sorry if this message is useless.

What would it take to support brew, some macOS package manager?

I see that system-packages already supports quite a few different package manager. Would it be more or less straightforward for this package to support some other package manager?

Support multiple face attributes for pacman's local packages

With pacman, local packages can be explicitly installed, dependencies or even orphans.
I'd like to combine the attributes of the local face and the (explicit|dependency|orphan) face.

I'm not sure how to do it however.
@thierryvolpiatto ?

helm-apt-file search ?

Is there anything like apt-file integrated into helm ?

Fedora alien package causes wrong packagae manager to get detected

alien is a package that lets you convert .deb packages into .rpm packages, and in order to work it installs dpkg. Since helm-system-packages checks for dpkg before dnf it will find dpkg, not find apt and fail. I found that placing dnf before dpkg in the helm-system-packages function fixed that.

helm-system-packages-eshell bugs

Hi, thanks for the package. Using helm for this type of querying is a magical experience. Installation, however, is pretty buggy at least on my setup. Using it twice within the same emacs session, I experienced bugs on both tries.

Setup:

• Fedora 30 (dnf)
• System distributed Emacs 26
• Melpa & package.el based helm setup, also w/ xterm-color.el.

Repro

M-x helm-system-packages RET <<a_package_to_install>>... select/navigate to it... f2 <<your_sudo_password>> RET

At this point, it shows the typical dnf pre-install summary and prompts for confirmation but misplaces the cursor by a single Tab character (see attached output). Continue anyways, pressing y RET like you normally would. When it fails (presumably due dnf's sanity check vs extra TAB) and the prompt appears again, press y RET to successfully install.

Now keep the *helm-system-packages-eshell* buffer, C-x b switch away and do some work. Later repeat above workflow to install another package. This time the install action fails completely returning run-hooks: Symbol’s function definition is void: helm-system-packages-refresh.

Inspecting helm-system-packages-refresh inside the *helm-system-packages-eshell* buffer confirm it is nil, and seems helm-system-packages--make-init has some missing related TODOs. xref reviewing calls to helm-system-packages-refresh did not make it clear how your package maybe effecting the associated eshell session at run-time though besides sending the initial constructed command.

Help?
See also eshell session output:
helm-system-packages-eshell_20190830.txt

Use package-kit

PackageKit is an high-level interface to handle package managers of many distributions including apt, dnf, pacman, portage, urpmi...

To get the list of packages, you have to write something like that (in a buffer with lexical-binding:t):

(let ((transaction (dbus-call-method
                    :system
                    "org.freedesktop.PackageKit"
                    "/org/freedesktop/PackageKit"
                    "org.freedesktop.PackageKit"
                    "CreateTransaction"))
      (count 0))

  (dbus-register-signal
   :system
   "org.freedesktop.PackageKit"
   transaction
   "org.freedesktop.PackageKit.Transaction"
   "Package"
   (lambda (&rest arguments)
     ; in `arguments`, you get the package name, the installation status and a summary
     (cl-incf count)))

  (dbus-register-signal
   :system
   "org.freedesktop.PackageKit"
   transaction
   "org.freedesktop.PackageKit.Transaction"
   "Finished"
   (lambda (&rest arguments)
     (message "Finished with %d packages" count)))

  (dbus-call-method
   :system
   "org.freedesktop.PackageKit"
   transaction
   "org.freedesktop.PackageKit.Transaction"
   "GetPackages"
   :uint64 4))

Suggestion: Support Windows's Chocolatey package manager

Since quite some people use both Chocolatey and GNU Emacs on Windows, it might be interesting to support it. I'll leave this here until I (or someone else...?) find(s) the time and patience to get it working.

It should, in theory, be derivable from the Guix implementation as far as I could see.

Integrate helm-apt

helm-apt has some features that might be lacking in helm-system-packages:

• Support for packages with different architectures.
• Support for filtered subset of packages.
• Force re-install.

Things I'm not really willing to integrate:

• Purge package: I think this is a misfeature of dpkg. Configuration files should not be "purged" when the user does not really know what this does.

@thierryvolpiatto: Opinion? Anything else?

Using preselect

I'd like to enable the :preselect feature so that the package name at point gets pre-selected.

I thought something along those lines would work.

(defun helm-system-packages-dpkg ()
  "Preconfigured `helm' for dpkg."
  (helm :sources '(helm-system-packages-dpkg-source)
        :buffer "*helm dpkg*"
        :preselect (and (thing-at-point 'symbol)
                        (concat "\\_<" (regexp-quote (thing-at-point 'symbol)) "\\_>"))))

It does not. I suspect this might have something to do with the fact that the source is built from
helm-build-in-buffer-source.

@thierryvolpiatto?

Consider making 3 separate packages for Melpa

Hi,
I think many people need only one of dpkg, pacman or gentoo, perhaps you could make separate packages in addition of helm-system-packages (all).
It is easy, you just have to create new recipe files for Melpa specifying the files to use and submit PR for each of them.
Thanks.