Support for passing arguments to yay and possibly others?

[freed00m]

Hi,

I recently stumbled upon issue with yay, where developers decided to not support and option via configuration file and restrict it only to a passed variable.

Would it be possible to implement aditional argument for pacui that would pass it on to the wrappers?

like

pacui --passedOption '--noconfirm'

that would pass it inside the pacui for

yay $passedOption ?

or maybe do the same with a enviroment variable?

EDIT: yay issue https://github.com/Jguer/yay/issues/170

[excalibur1234]

as far as i understand you, you want to be able to enter in your terminal for example

pacui -i 0ad --option "--noconfirm"

this would install the game 0ad using yay and the option "--noconfirm" is passed to yay. this means in the background pacui would execute the command

yay -S 0ad --noconfirm

---

can you describe a use case, in which this would sense? maybe you want to write a wrapper function in your .bashrc for calling pacui?

currently, it does not really make sense to me. if i already know (and want to type) the full package name i want to install, i can use yay -S 0ad directly in my terminal. in this case, i do not use pacui at all. when yay offers a config file / environment variables for configuration, you can use it and adjust its behavior to your liking. if yay does not offer a config file / environment variables for configuration (and the developer does not implement it), you should use a differnt AUR helper.

[Morganamilo]

is --option documented anywhere? that's basically what they were asking for in the first place.

[excalibur1234]

no. "--option" does not exist yet!

it was just an example in order to better understand OP's intention. if he (or you) can describe a use case, in which such an "--option" flag could be useful, i can understand why and how "--option" should work.

at the moment, i just think that yay -S 0ad --noconfirm is a much shorter command than pacui -i 0ad --option "--noconfirm". therefore, i would never use "--option", even if it existed.

please convince me there are situations in which "--option" is actually useful.

[Morganamilo]

I'm guessing op wants to do :

pacui
3 #install packages
#pick the package they want
<Enter>
#have yay do the install in no confirm mode

As I said in the original issue, Yay does not support noconfirm in the config file because noconfirm is not something that should be taken lightly as you can miss important warnings and you risk the danger of building unchecked pkgbuilds.

OP's original suggestions were my suggestions to him for getting the behaviour through pacui. If you think that option doesn't have much use I'll take your word on it.

My suggestions were intended as "if you really must have --noconfirm". My personal option on this is don't use --noconfirm

[excalibur1234]

IF i create an "--option" flag, it would never work in regular pacui. it would only work when pacui is used directly from the terminal. actually, integrating an "--option" flag would not be a lot of work (i just had to call aur helpers with an already used variable). but my personal option on this is it does not make sense to me (until someone can convince me otherwise).

btw, after seeing @Morganamilo fail to call the help page in pacui, i have added an option, which adds "pacui --help" support: f8fc5bfd9e444117a15d2126a982827d1f776d90.

[Morganamilo]

If you were to implement this I would go with the environment variable over a flag anyway. Easy to just but in your .bashrc and never have to worry about it again.

Plus like I mentioned in the other issue $AURHELPER would be nice to override the aur helper pacui uses. (I can't use pacui with yay while I have Trizen installed). Plus that would allow the user to use unsupported AUR helpers as long as the syntax matches Pacman's.

[excalibur1234]

i agree that environment variables are nicer than a config file. but i want to avoid both as much as possible. currently, i use a "bash strict mode" (see these 4 lines of code: https://github.com/excalibur1234/pacui/blob/master/pacui#L17), which means i have to disable the strict mode every time i use an environment variable (because environment variables are not defined). i already have to disable the strict mode when i use variables such as $HOME. this is a hassle an beats the point of using the strict mode anyway.

maybe, i will end up implementing support for many environment variables, but i try to avoid this as long as possible. your idea for an $AURHELPER environment variable is tempting, though...

[freed00m]

OP here:

Basically I only need few AUR packages and I trust the maintainer of those few. When I use pacui for updating it now requires me to attend the sysem update process during selection of packages that I don't want to upgrade. Which I always want all so it is bothering me.

The behaviour was ok before the option was removed from configuration file of yay.

Since pacui is a bash script with strict mode and It has no configuration file, the only reasonable way I could think of was to pass a variable to pacui aliased in .bashrc like alias pacui='pacui --option "--noconfirm"' so when I would launch pacui from my terminal it would now it should be passing the option to yay.

Again, it's no bug on either side. Just the good intention of yay's devs to discourage using AUR in noconfirm introduced new annoyence for me (and possibly others) when I am just updating my system from distro repository.

Maybe yay was never intended for system upgrade but that's the current state it's used here in pacui.

[Morganamilo]

Well I really don't recommend this but you could override yay with a bash script.

#!/usr/bin/sh
/usr/bin/yay --noconfirm $@

Place that in something lke ~/.local/bin and add it to your PATH.

[freed00m]

@Morganamilo thx very much, I didn't know I could override in user's ~/.local/bin , but why not :)

[Morganamilo]

PATH works left to right, as long as you do PATH=$HOME/.local/bin:$PATH the commands in ./local/bin should have the highest priority.

[excalibur1234]

updating all (AUR) packages at once actually makes sense, especially for AUR helpers, which do not store your previously installed packages and compare every new PKGBUILD file against it (and do not ask you again to check it, if it has not changed). thanks for this use case.

i might need a couple of days, but i think i will implement this. do you have a suggestion for a better name than these?

--option
--pass
--argument
--flag

[Morganamilo]

--aurflags is my preference along with --aurhelper if you want to implement that too.

[excalibur1234]

i have just added a huge commit: bd6da528fa65e30eca952a4ad7c98d0a818e70d1 it contains about 350 new lines of code.

there is now a new 'flag' option for pacui. this flag can be used with these options (and it does not have any effect on other options):

• update
• install
• remove
• roll back
• edit config files
• force update aur
• downgrade

examples of usage:

• using it in a bash standard compatible way: pacui -i --flag="--noconfirm"

• using it pacui style (i.e. however you like): pacui u flag --noconfirm pacui flag=--noconfirm i 0ad pacui --I --bash --FLAG --asdeps

i could not test this with all AUR helpers (and without any AUR helpers) with every pacui option it works for. please test this and report back, if you find any bugs, open a new github issue.