Skip to content
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] Merge query operations' results and track them for subsequent installation operations #502

Open
riotrah opened this issue Jan 2, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@riotrah
Copy link

riotrah commented Jan 2, 2023

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
Copy link
Owner

rami3l commented Jan 3, 2023

@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 rami3l added the enhancement New feature or request label Jan 3, 2023
@rami3l rami3l changed the title Merge query operations' results and track them for subsequent installation operations [Feature Request] Merge query operations' results and track them for subsequent installation operations Jan 3, 2023
@rami3l
Copy link
Owner

rami3l commented Jun 30, 2023

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.

@rami3l rami3l added this to pacaptr Aug 15, 2023
@rami3l rami3l moved this to To do in pacaptr Aug 15, 2023
@rami3l rami3l moved this from Blocked to Idle in pacaptr Nov 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Idle
Development

No branches or pull requests

2 participants