Allow setting a custom command for AUR packages instead of manually adding support for AUR helpers

[Tank-Missile]

AUR helpers come and go. First I moved from pacaur to yay, and now I'm trying to figure out where to move to next now that yay is in maintenance mode. There are many AUR helpers even beyond what the wiki lists, and supporting all of them manually means not all helpers end up getting supported. Asking for a helper to be supported means waiting for the next release before it can be used with octopi. To alleviate this maintenance burden, why not toss out the old method of supporting AUR helpers and leave it up to the user? Environment variables could be used for supplying the AUR command with the list of packages to be installed, removed, upgraded, etc. Here's what the settings menu could look like:

[aarnt]

Hi @Tank-Missile ,

I understand your point and it'd be cool if we could easily solve this.
The problem is that it is not enough to specify the command that the helper uses to install packages. It needs also the command to check for outdated AUR packages and, the worst, the code to build the package list of searched packages.

You can take a look at

octopi/src/package.cpp

Line 1083 in 1234d31

/*

to see what I'm talking about.

[Morganamilo]

I feel it would be a lot easier to just use the AUR RPC for this instead of relying on a helper.

[aarnt]

@Morganamilo

You mean this one: https://git.archlinux.org/aurweb.git/tree/doc/rpc.txt ?

[Morganamilo]

Yes, though you can find the rendered version of that link here: https://aur.archlinux.org/rpc

[aarnt]

Nice.
So your idea is using RPC to search and get info and helper to install/update/show outdated pkgs?

[Morganamilo]

Yeah that's probably best. Use the RPC to get information, use the helper to actually do stuff.

[aarnt]

@Morganamilo
Hmm, thanks. I'll take a look and make some tests.