-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Add aurman plus ability to use the specific AUR helper #40
Comments
such a feature would require one of the following:
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? |
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? |
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:
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. |
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. |
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. |
with commit 249533e, i have added an easy way to change your AUR helper. simply modify the "AUR_Helper" variable in line 30:
|
Thanks, at least one can easily set helper by editing the script file. |
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. 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. |
aurman support added: 82f4497 please test and report back. |
Thanks! Looks like it works. Some observations though:
|
thanks for testing!
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.
|
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. |
this is exactly what i am thinking - IF it does not take too long. |
aurman supports -Si as of now. Currently only with |
Went faster than expected, the current |
As aurman -Si switch is implemented, we are good to add aurman to both variants. |
installation and package info works. this means that aurman support in pacui is completed. |
If you decide to finish the |
thanks for your opinion about the speed of aurman. the descriptions are already adjusted. look here: 1839739 |
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. |
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). |
#40 (comment) - rofl. I'd say one should remove |
@polygamma @excalibur1234 Re several shells you can keep the line of $PACUI_AUR_HELPER in each shell found. As to helpers priority IMHO two major factors should be considered
I'd suggest pakku, yay, pacaur or trizen start of the sequence as python based helpers are just noticeably slower. |
@seafox, nope, I am not taking this seriously, I am just reading this and laugh about it |
@polygamma, bad for you and for the aurman, as so far it clearly shows the worst performance. Maybe a cold shower would help? |
computer scientists do not take a shower |
may I remind you that was my request to include your helper, just look at OP
just wanted to help, but apparently they are flying above the sky ) |
the previous order of AUR helpers was based upon their feature set almost 6 months ago.
p.s.: i had only updated pacui's code before. readme is now updated, too. |
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. ... means significant diff in-between. Overall, I'd suggest
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. |
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 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.
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:
let's agree that this list is better than the current order, but not perfect. |
regarding pikaur: actionless/pikaur#201 |
@excalibur1234 |
aur helper priority has been adjusted: dfdedbc |
As per title. Ability to use the one from installed AUR helpers instead of a helper chosen in some fixed order.
The text was updated successfully, but these errors were encountered: