[Feature Request] Merge query operations' results and track them for subsequent installation operations

[Rayat Rahman]

Firstly, very cool project, thanks so much for OS-ing it.

Would love to contribute, tho I am completely unfamiliar with Rust for now, but it does seem like every OSS CLI tool is either rust or go, so might as well learn at some point.

My request:

I'm going to be vague about terminology like "query/installation operations", as I eagerly await #32 and don't want to jinx that decoupling from pacman too soon 😉

1. Operations that query packages could (per invocation opt-in, or globally configurable as default etc) "merge" the results of the enabled pms.
   2. Realistically, or UX-wise, it would really likely be the equivalent of returning x-many tables/lists of packages, with _x_ == num of pms
2. And similarly, ops that install packages would search over the various pms
   1. With a decent likelihood of overlap, we have diff options for resolution:
      1. Bork, and echo "so and so conflicts, pls specify amongst these:..."
      2. Auto proceed to installing via the already-user-or-per-os-configured-default pm
         3. if not otherwise opted-out perhaps via new flag
         4. maybe consider new config options for just this priority/resolution situation if ppl want it?
      3. Offer a readline-y/fzf-y/gum-y prompt to select amongst whichever ones were found
3. Again similarly, same for upgrading and uninstalling
   7. Tho of course, instead of querying the "remote store/repos" and then merging etc, we'd want to query only the locally installed stuff

---

I don't think this will really be a big value-add for linux, nor likely mac, as my experiences on both reveal few experiences with packages not being the os-default pm but being available on alternatives - eg, I've had like 2 occasions where port had something brew didn't.

But on Windows, I juggle so constantly between searching and then installing amongst scoop, choco, winget, that I wrote a pretty shitty/hacky powershell script to kinda do my suggestion above, converting/parsing the returns of each pm into PSCustomObjects and using gum to filter/install/confirm etc.

But I'd have to do some more heavy lifting to have that work nicely on mac and linux, which I've started using pwsh on, and also for supporting operations like uninstalling.

Not opposed to doing that, but I think this project already has significant progress made that might obviate doing that in my own hacky way.

---

Anyways, thanks again!

[rami3l]

@riotrah Thanks a lot for your detailed feedback!

Your wish to be able to dispatch to different package managers in one go is absolutely reasonable, and I personally have that need as well from time to time.

As a matter of fact, I even made pacaptr async exactly to get ready for this sort of extension, which might require launching several subprocesses simultaneously.

---

However, the more I learn about PMs, the more I see pacapt(r)'s work as superficial and cosmetic, and your proposal actually made that even clearer.

A look at the compatibility table might get you a better feeling of what I'm trying to say: different PMs have slightly different approaches towards the mostly identical problem of package managing, and that's why there seems to be no real common operations among PMs.
Even under -S, the supported operations are hardly identical, not to mention the keyword format and even package names (icy/pacapt#44) 🤦‍♀️
... and we must somehow get that clear before actually tackling #32.

---

That being said, it'd be great if you could share your Powershell script somewhere as a reference, even it's only specialzed for the most common operations like -S, so that it might be easily ported to other scripting environments like python and babashka.

I started my life as a developer browsing through pacapt's issue list, and now I have the feeling that there might be something even shinier trying to get out of this package managing mess 😀

[rami3l]

I'm recently thinking about what could be included in the "next-gen" pacaptr, which leads me back to this issue,

In theory it could indeed be possible to define a "composed package manager" that might do something similar to what you want, and it would be interesting to figure out what laws should each pacman command obey when multiple Pm implementations are combined in an ad-hoc fashion.