Features propositions

[TimotheeMathieu]

Hello,

Thank you for this tool this is really great. While learning to use this I implemented a few additional features and you may be interested in merging some here.

Features:

• Have description of packages show up as comments in unmanaged and show Basically, the output of unmanaged or show will print the package and its description in comments. Example:

  alsa-firmware #  Firmware binaries for loader programs in alsa-tools and hotplug firmware loader
  alsa-lib #  An alternative implementation of Linux sound support
  alsa-oss #  OSS compatibility library
  alsa-plugins #  Additional ALSA plugins
  alsa-utils #  Advanced Linux Sound Architecture - Utilities

  This is very useful IMHO to sort through the packages, some of them I don't remember what they do. My first reflex with pacdef was to do pacdef unmanaged > misc, import the group misc and begin sorting from there but with description this process was a lot easier.

• multiprocessing when processing packages using python's multiprocessing library. The program is then a lot faster in particular when there are a lot of packages installed, and it is easily made parallel.

• I also added an argument in the pacdef.conf that contains command-line arguments passed to AUR helper when removing. In particular, I used the --cascade argument to delete packages that were dependencies of the packages I deleted.

Tell me if any of these features is of interest and I can do a PR.

[steven-omaha]

Hey, it appears GitHub has eaten my previous reply somehow. :/ Let me try again.

Thank you for your suggestions! I will address them individually.

Have description of packages show up as comments in unmanaged and show

ATM I'm hesitant to implement something like this.

• I want my tools to follow the unix principle of "do one thing and do it well", so having an comment on every line is unnecessary IMO.
• But, I have something similar implemented under pacdef review, where you can press i to show package information. Please check it out and let me know if this fits your needs.
• You could also do something like this, which could be turned into a shell alias or shell function.

  $ pacman -Qi $(pacdef unmanaged) | grep -iB2 description 
  Name            : alsa-firmware
  Version         : 1.2.4-2
  Description     : Firmware binaries for loader programs in alsa-tools and hotplug firmware loader
  --
  Name            : alsa-oss
  Version         : 1.1.8-4
  Description     : OSS compatibility library
  --
  Name            : alsa-plugins
  Version         : 1:1.2.7.1-1
  Description     : Additional ALSA plugins

multiprocessing when processing packages using python's multiprocessing library

I did not think of that! I would be interested to see some concrete numbers for the actual improvements (benchmark).

I also added an argument in the pacdef.conf that contains command-line arguments passed to AUR helper when removing.

That would be a great addition! Please open a PR for that if you would like.

FYI: I'm currently rewriting pacdef in Rust (not here, but in a private repo). Once that is published, performance won't be an issue anymore.

[TimotheeMathieu]

Ok, I did the PR (PR #12 ). For the performance part on multiprocessing, this is only an issue if the first feature is implemented, it is computationally intensive to get all the description, parse them and add them as comment. And also I may have done it in a non-efficient way.

multiproc is 4 times faster in my case 2min against 30s when descriptions are implemented. With your implementation without descriptions, the process takes 0.07s even with my almost 2000 packages installed.

I like the description as comments, I like literate programming a lot and similarly here I want the explanation to be in the code, right where it is needed. But I understand your point, it is indeed a bit redundant with the review function, although IMO this allows me to delete unwanted packages faster (just by deleting the line). The downside is that it becomes computationally intensive when there is no real reason to be.

[steven-omaha]

The downside is that it becomes computationally intensive when there is no real reason to be.

Indeed. That's also one of the reasons why this should not be implemented.

Thanks for the PR!