feat: add pacman

[clo4]

This is still WIP. exclusiveOn and dependsOn don't quite work for pacman. We need full "options with options".

[withfig-bot]

Overview

src/pacman.ts:

Info:

[withfig-bot]

Hello @SeparateRecords, thank you very much for creating a Pull Request! Here is a small checklist to get this PR merged as quickly as possible:

• [ ] Do all subcommands / options which take arguments include the args property (args: {})?
• [ ] Are all options modular? E.g. -a -u -x instead of -aux
• [ ] Have all other checks passed?

Please add a 👍 as a reaction to this comment to show that you read this.

[fedeci]

@SeparateRecords using subcommands to describe this kind of options isn't a feasible solution?

[grant0417]

@fedeci does saying that is a subcommand currently work, otherwise are you able to impl this?

The cases this would have to cover are:

$ pacman -Ss
$ pacman -S --search
$ pacman --sync -s
$ pacman --sync --search

[fedeci]

It works in the sense that they are correctly suggested and treated like subcommands, but for example -Ss wouldn't work while -S -s would.

[grant0417]

What would we need to do to support the -Ss case? That is the primary way pacman users would expect the command to work and some other arch utils work that way as well.

[grant0417]

Would this be an additional flag on the subcommand or impl be default?

[clo4]

Might be interesting to have a parser directive like parseSubcommandsAsOptions which uses the option-parsing logic for subcommands?

[fedeci]

I think for the moment additionalSuggestions may come to our help to achieve that result easily. @SeparateRecords parserDirectives would apply globally but in some cases we only want it for some options.

[mschrage]

@grant0417 worthwhile keeping this open? Less relevant now, since we are not focused on Linux support.

[brendanfalk]

Going to close this draft for the moment. Can always re-open. @clo4 Any interest in getting this up and running again?