[Feature Request] Add aurman plus ability to use the specific AUR helper

[seafox]

As per title. Ability to use the one from installed AUR helpers instead of a helper chosen in some fixed order.

[excalibur1234]

such a feature would require one of the following:

• a configuration file (which needs to be created, filled with defaults, and read)
• optional environment variables, which can be set by the user. i am still hesitant towards these solutions. if possible, i want to avoid them.

can you describe a use case, in which it would be beneficiary to (1.) use multiple AUR helpers at the same time (2.) which cannot be solved by changing the (fixed) order currently used in pacui?

[seafox]

Env. vars are not quite suitable for settings expansion. Sure you can think about adding a config file to customize settings. Its absence would mean defaults. As to use case, I don't understand need for multiple helpers usage "at the same time". But, many keep several AUR helpers in their systems, so ability to choose the preferred one should be a must. How otherwise you supposed to select the helper, by directly editing the script each time after it has been updated?

[excalibur1234]

i can make an exemplary case, which describes how to remove support for one AUR helper:

lets assume you have pikaur and yay installed on your system (and need both) but you want to use pikaur in pacui. this means you have to remove all parts of yay support from your "/usr/bin/pacui" file in the following lines:

• line 75:

      elif [[ -e /usr/bin/yay ]]
      then
  
          # execute "yay -Syu" command:
          if ( yay "$argument_flag"-Syu )
          then
              # only set $install_successful=true, if the command "yay -Syu" was executed without errors
              install_successful=true
          else
              install_successful=false
          fi

• line 238:

      if [[ -e /usr/bin/yay ]]
      then
          yay -Cd
  
      el

• lines 318, 437, 1706, 2006, 2046, 2089, 2091, 2093, 2405, and 2406:

  [[ -e /usr/bin/yay ]] || 

• line 484:

                      elif [[ -e /usr/bin/yay ]]
                      then
                          yay -Si {1}                                             # this does not work yet, because "yay -Si <repository package>" needs root privileges --> destroys layout of fzf!

• line 526:

          elif [[ -e /usr/bin/yay ]]
          then
              yay "$argument_flag"-S $pkg                                         # ATTENTION: (i do not know why but) using quotes (" symbols) around $pkg variable breaks AUR helper and pacman

• line 1572:

      elif [[ -e /usr/bin/yay ]]
      then
          yay "$argument_flag"-Syu && yay -Syu --devel --needed --noconfirm

• line 1678:

          elif [[ -e /usr/bin/yay ]]
          then
              yay "$argument_input"

• line 1717:

              elif [[ -e /usr/bin/yay ]]
              then
                  yay "$pkg"

if you know a little bit of bash syntax, you can also search for "/usr/bin/yay" and remove it (and surrounding if-statements or OR-operators).

you do not need to update pacui regularly. you can keep it until it breaks. this should make your effort worthwhile at least until the next major pacman (or AUR helper) update.

[excalibur1234]

if more people want an easy way to choose their preferred AUR helper, i could introduce an editable global variable, which determines the default AUR helper. this would eliminate the need to delete yay support (as described above) and instead you would only need to change a single word in pacui's file.

i will think about your idea a bit more before i implement it.

[seafox]

you do not need to update pacui regularly. you can keep it until it breaks. this should make your effort worthwhile at least until the next major pacman (or AUR helper) update.

Well, I don't think we should rely on pacui package immunity to changes. Especially when AUR helpers are quite volatile subject and changes come all the time. Like if you select to use aurman, you might want to have some of its particular unique features like --deep_search --do_everything aurmansolver, etc. While variable probably would suffice for a single helper selection, the mentioned expansions would be messy to implement without a sectioned config file. But that might become another project :)

[excalibur1234]

with commit 249533e710b126004e8ffcdbc7c7bafb9d3f2ca4, i have added an easy way to change your AUR helper. simply modify the "AUR_Helper" variable in line 30:

# here, the preferred AUR helper can be set manually by the user. if AUR_Helper="", the installed AUR helpers are detected and one is chosen automatically:
AUR_Helper=""

[seafox]

Thanks, at least one can easily set helper by editing the script file. What about adding aurman? It has no -Si option yet.

[excalibur1234]

no -Si option is bad. but maybe it will come some day...

i almost installed aurman yesterday, but then hesitated, because the PKGBUILD executes a "setup.py", which means i have to download the package manually, unpack it, read the entire "setup.py" file and then install aurman. i have to do this every time aurman releases an update or manually setup a version control system just for aurman. i see that aurman seems to be really popular, but i am not (yet?) prepared to do so much work, just for an AUR helper...

please contact me again when aurman supports -Si. then, you can give me a list of equivalent aurman commands (to the commands listed in my second post) and i can still add support for it without the need to install it myself.

[seafox]

Just check setup.py directly from any browser. -Si depends on this, hopefully solution will appear in July.

[excalibur1234]

aurman support added: 82f4497454bd2ab9596a8283d81499c52cbfa4af

please test and report back.

[seafox]

Thanks! Looks like it works. Some observations though:

• When performing System Maintenance I got the following:

  checking systemctl ...
  /usr/bin/pacui: line 354: ((: UNIT             LOAD   ACTIVE SUB    DESCRIPTION
  > 0 : syntax error in expression (error token is "LOAD   ACTIVE SUB    DESCRIPTION
    > 0 ")

• Package descr & dependances updates are pending (obviously)
• Install package so far causes an empty descr part due to --info switch aurman implementation pending status (obvious as well)
• Are you making move to provide an alternative location for the used AUR helper config in pacui config (as for aurman)? That probably would provide further flexibility, like having two separate sets of configs for aurman - when run as is, and when run from pacui (different options would be possible).
• Unrelated pacui UI observation: Except the red line item, the bold letters for item selection are not very readable / distinctive, maybe making other letters more gray or choosing separate color for the letters would improve usability a bit (nitpicking).

[excalibur1234]

thanks for testing!

Except the red line item, the bold letters for item selection are not very readable / distinctive, maybe making other letters more gray or choosing separate color for the letters would improve usability a bit (nitpicking).

this depends on your theme setting in your terminal emulator / bash. take a look at my current setup: https://i.imgur.com/3URjJrE.png

making their color distinct would be kind of hard, because pacui tries to be as compatible as possible, which means it does not set any colors but uses the colors set by your system. this can lead to a completely different look, e.g.: https://s8.postimg.cc/q9b9yio6d/2015.11.22-1.png

Are you making move to provide an alternative location for the used AUR helper config in pacui config (as for aurman)? sorry, but not currently. i try to avoid having a config file for pacui.

[seafox]

You are right, Linux style with Hack Regular 10 is probably your current console theme.

I think you are free to close the ticket any time, hope it'll appear in non-git version at least after aurman -Si switch is ready.

[excalibur1234]

it'll appear in non-git version at least after aurman -Si switch is ready

this is exactly what i am thinking - IF it does not take too long.

[polygamma]

aurman supports -Si as of now. Currently only with aurman-git, but that feature will be included in the next release, probably in a few days

[polygamma]

Went faster than expected, the current aurman release 2.16 includes -Si.

[seafox]

@excalibur1234

As aurman -Si switch is implemented, we are good to add aurman to both variants.

[excalibur1234]

installation and package info works. thanks a lot for the fast integration.

this means that aurman support in pacui is completed.

[seafox]

I meant missing descr + opt dependence for both pacui and pacui-git versions:

[seafox]

@excalibur1234

If you decide to finish the aurman include, please keep the optimal AUR helper as the first choice (perhaps it's trizen currently) in non-devel version of pacui. Aurman definitely has its strengths, but feels rather slow in terminal, comparatively. Python isn't the quickest language, but this not only shows the math and the creator's attitude, but aurman also feels slower in general responsiveness.

[excalibur1234]

thanks for your opinion about the speed of aurman.

the descriptions are already adjusted. look here: https://github.com/excalibur1234/pacui/commit/18397395f37b527bac84c4762c2c4a589744f4fd the PKGBUILDs are not yet uploaded, though. i will do this with the next release.

[seafox]

Looks like the script line 42 has an excessive @ sign, as in the sample only "yay" name is required. Also, the doc has this fragment.

As many wouldn't bother to explicitly set the env var (Hint: you can make pacui menu item to set the var into .bashrc and reload 'exec bash' after setting!), the first helper shouldn't have the worse possible speed, it's not only my opinion based on usage, but also straight math. Please take a look at the testing script I've cooked just for comparing execution time of AUR helpers. Quickest is yay, after first load (of GO) but has missing features like absence of dates for packages and also has no sorting on search (by popularity etc.). Trizen still has rough edges shown as excessive delays (see and test -Si apparmor) on fetching. Yaourt has not had an update this year, so it shouldn't be a candidate for the default all-round helper either. Python speed makes aurman and pikaur helpers feel slow, especially in TUI like pacui. As pacaur isn't developed anymore, the best choices for the time being are pakku (very responsive written in Nim language, in line with pacaur, also max visual compatibility with pacman like properly formatted timestamps etc.), and yay, which has the potential to compete for the first choice with pakku and trizen.

exec-time.sh.txt

[excalibur1234]

i assume you were talking about the $ symbol (and not the @ symbol) in line 42. it has been removed. thanks!

also thanks for the hard numbers. i will rethink the default order pacui chooses its AUR helpers.

i do not like a "settings page" for pacui at this point in time, because it would need to be really flexible. for example: i use zsh, so modifying my .bashrc file would not make any sense for me. i know there is a .zshrc file, but i would need to choose which shell is used (and do this every time, because the user could have changed the shell). also, i would need to restart the shell every time in order to use .bashrc/.zshrc file. restarting the shell might mess with your shell history (when using multiple terminal windows at the same time). doing stuff like that can lead to nasty problems in the future, which i want to avoid. i hope you understand.

[polygamma]

https://github.com/excalibur1234/pacui/issues/40#issuecomment-403675454 - rofl. I'd say one should remove aurman completely, seems like it's literally unusable. Crazy, how aurman -Ss core lasts over 4 seconds, the aurman developer should probably start writing hello world programs again, how incompetent.

[seafox]

@polygamma good you appeared here, that means you took the issue seriously or concerned at least. When faced with hard facts showing seconds behind in real time performance, instead of "supposedly hypothetical" execution speed difference 70x in just one invocation, it's time to re-evaluate. Perhaps it's time to switch to faster language AND start to take into account clearly pointed out several dozens time exec time diffs seriously at last?

@excalibur1234 Yes indeed, you are right, $ not @, but please correct .md also (see the pic). BTW no need to re-set env var when set in .bashrc once (so it's valid only for the described in md alternative).

Re several shells you can keep the line of $PACUI_AUR_HELPER in each shell found. && exec bash doesn't have global effect, only for the current terminal window, so one would be able to re-test with another helper right there. But yes, it's not an elegant solution, and, as I suggested before, having $XDG_CONFIG_HOME/[pacui/]pacui.conf with fall back to $HOME/.config/[pacui/]pacui.conf would be much cleaner and natural.

As to helpers priority IMHO two major factors should be considered

• overall compatibility and standard switches and options feature completeness
• overall response time as the matter of pacui TUI usability comfort

I'd suggest pakku, yay, pacaur or trizen start of the sequence as python based helpers are just noticeably slower.

[polygamma]

@seafox, nope, I am not taking this seriously, I am just reading this and laugh about it

[seafox]

@polygamma, bad for you and for the aurman, as so far it clearly shows the worst performance. Maybe a cold shower would help?

[polygamma]

computer scientists do not take a shower

[seafox]

I'd say one should remove aurman completely,

may I remind you that was my request to include your helper, just look at OP

computer scientists do not take a shower

just wanted to help, but apparently they are flying above the sky )

[excalibur1234]

the previous order of AUR helpers was based upon their feature set almost 6 months ago. what do you think about the following default order (i considered feature set, speed, security, and popularity):

• yay
• aurman
• pikaur
• pakku
• trizen
• yaourt
• pacaur

p.s.: i had only updated pacui's code before. readme is now updated, too.

[seafox]

yaourt: if I got right it's installed in Manjaro repo by default, but maybe it's time to replace it in shipped releases due to being obsolete, no updates this year, should probably be disqualified; also as feature set and security wise, so it's easy the last one. pacaur as number 1 for many years should be rated higher, it has no omissions and still performing. yay -Si doesn't show dates except out-of-date cases, opposite to pakku that shows no out-of-date in -Si. Speed wise: yay pakku pacaur trizen ... pikaur ... aurman

... means significant diff in-between.

Overall, I'd suggest

1. pakku
2. yay
3. pikaur
4. pacaur
5. trizen
6. aurman
7. yaourt

If and when the computer scientist will optimize his code and approach the speed of pikaur and stops throwing clauses like "personally not interested in -info switch as I don't use it...", the aurman could take the third place. All that is subjective of course.

[excalibur1234]

IMHO, features are more important than speed. which features you prefer is subjective.

aurman, pikaur, and yay are the only "full featured" aur helpers according to this table: https://wiki.archlinux.org/index.php/AUR_helper i find "Summarizing package upgrades" and "Native pacman" especially important. therefore, i placed these 3 aur helpers at the top. they are sorted further by features, popularity, and speed.

you are right about pacaur and yaourt. i should put yaourt at the bottom. i still want to put pacaur almost at the bottom, because it is no longer supported and can break at any moment. i want to discourage the use of pacaur. i still want to keep yaourt, because

• supporting it (further) does not cost anything
• all my example commands in the help page use yaourt
• yaourt is (still) in the manjaro repositories (together with yay, pacaur, and trizen)

regarding pakku/yay: yay does not show dates, but it has a "out-of-date". additionally, it shows a warning at the top, if a package is orphaned.

i see the current list of preferred aur helpers like this:

yay
aurman
pikaur
pakku
trizen
pacaur
yaourt

let's agree that this list is better than the current order, but not perfect.

[polygamma]

regarding pikaur: https://github.com/actionless/pikaur/issues/201

[seafox]

@excalibur1234 Yes, the last list is indeed better. I see yay is in stable community repo, but yaourt illogically lost in extras ) BTW why not to rewrite examples for yay? As to the "official" AUR helper list, I thing there should be added a cleaner distinction regarding 'Native pacman' as some helpers have ability to have either default pacman or switched to batch mode, default or not. As many have config files, the importance of the default setting is lessened. Anyway, thank you for ability to set preferred helper without editing the script, that should keep everyone satisfied! (although it would be more flexible & shell independent when made with optional pacui.conf file...)

[excalibur1234]

aur helper priority has been adjusted: https://github.com/excalibur1234/pacui/commit/dfdedbcabced0e889dd96446def449774dffa0ea