why not xbp install , xbp query or xbp remove ?

[Hierosme]

I'm motivate to code a xbps wapper command, but before anything i asking why it's not all ready the case.

Look command set of xbps permit a easy refactoring, by create a frontal command for pilot each others.
That is not a tonne of work and i all ready have make it with succes with python, argparse and CMD.

The goal look simple: have a unique entry point call xbp where the args determine which command will be use.
Exemple

xbp install toto == xbps-install toto
xbp query -Rs toto == xbps-query -Rs toto

etc etc...

where/when my idea it is good for final user ?

by use CMD coupled with argparse we can have :

• a SHELL for xbp, then have a interactive session with humain user
• a scripting language for xbp (same as interactive session but in descriptive file)
• a capability to use CLI without file description and interactive session
• a completion it follow xbps tools command set

Look magique but that not so hard to do...

If that feature look good , and look to save the world for fews i can propose a python proof of concpet.
I not suppose to be the only one it have speack about it, it have a technical raison or a political raison for that ?

I'm not sure about python will be the best choose for it, but as PpC why not.

Regards

[classabbyamp]

#!/bin/sh
bin="$1"
shift
exec "xbps-$bin" "$@"

no python needed

[Hierosme]

In that case a simple naive implementation can be done with alias command too, but that is not my point.
In fact i totaly not propose a naive wraper, i speack about a True human interface.

The last line of my previus post was:
I'm not sure about python will be the best choose for it, but as PoC why not.

From my point a naive wraper approch is a workarround compare to a cosolidate human interface

Then i propose a python PoC of a User Interface, with a SHELL>Read–eval–print loop it will permit easy dev for future TUI / GUI.

The modular approch of xbps permit to make a robust human interface ready to be use by TUI/GUI as backend.

Regards

[fearlessgeekmedia]

Probably not what you're looking for, but I've written a little something at https://github.com/fearlessgeekmedia/xbpsman

[Hierosme]

Thanks for you response.

Probably not what you're looking for, but I've written a little something at https://github.com/fearlessgeekmedia/xbpsman

The final target look really close yes, We clearly look for the same type of end result ... (should not divide our strong)

Actually i propose a backend UI Interface for permit TUI/GUI frontal, because if it backend componant do not exist the difficulty will be push near the fronted, and that is not a good practice.

From my point a backend like that should use a event bus signal, that let allway the UI responssive on front of the human user. The conversion CLI to TUI/GUI is in general a simple event bus message wrapper as backend, and a TUI/GUI it consume they events. All the game will be to not have strange dependencies.

i permit warning about xbpsman:
I really recommend to not use termcap in hard, an other approch can simply to use dialog lib,
That because dialog come from hight level widget on top of ncurses. Then will work with a tonne of different terminal, like serial port, putty, old console, etc...

OK it week end i'll focus to my PoC and send you results.
I 'll clearlly provide a backend usable from xbpsman > dialog
my SHELL script skill is really limitated compare to python/perl/tcl -> ncurses/gtk/qt. But i have good rest with dialog...

Regards

[Hierosme]

I have take a look ,
Unfortunally look very hard to keep xbps philosophy with an abstract CLI entry point.

The more close i have found was done for xbps ansible module:
https://docs.ansible.com/ansible/latest/collections/community/general/xbps_module.html

done by it code:
https://github.com/ansible-collections/community.general/blob/main/plugins/modules/xbps.py

that is a static binding ....

Without a xbps CLI wrapper entry point, a TUI/GUI application must include a huge backend for a huge static binding.
From my point it type of backend is not the responssability of the TUI/GUI maker.

The xbps wrapper CLI entry point should be native to xbps project for have a luck to maintain a SDK for TUI/GUI over the time.

Hope other one will understand the necessary of a XBPS Common Interface for GUI/TUI developpement

[paper42]

You should write a PackageKit backend if you want xbps to integrate into existing GUI package managers. Anything custom will only be used by a couple projects and incompatible with the rest of the world.

[Hierosme]

@classabbyamp got you point , and 100% agrea .

If the final target is GUI Package Manager PackageKit is the way.

Unfortunally due to GUI need PackageKit have long chain dependencies, polkit, dbus , etc ... (XDG), but clearly that is the common stack for graphic desktop.

I more thing an eventual xbps wrapper command line , like what it have been done with apt command.
The single entry point apt have appear long time after apt-xyz .

For a TUI a static binding over a single entry point xbps will add stability, compare to bind multiple tools xbps-XYZ.
Same for ansible xbps modules where more option can be add with less code needed.

Anyway thanks for you response.

My offer is still active, i can create a POC of a single entry point of xbps command and implement pkcon args like documented on man:
https://www.systutorials.com/docs/linux/man/1-pkcon/

In fact i dont know what is the best approch, i see an inegration lake and try to go a head.
I cant address a PackageKit project, i suppose it have all ready been a topic here.

[Hierosme]

xbps packagekit have all ready been adressed:
https://github.com/pandom79/xbps/tree/packagekit

Annonced here:
https://www.reddit.com/r/voidlinux/comments/lmquno/xbps_backend_for_packagekit/

The trouble with PackageKit is the depencency to Dbus and Polkit ....

in case i'll wait for a Packagekit supprot then make my TUI coupled with pkcon.
Without Common Interface look impossible to me to stabilize and maintain overtime.

Continue to think about an eventual xbps wrapper command line , will be a better canditade , and will limit dependencies.

[Chocimier]

Without a xbps CLI wrapper entry point, a TUI/GUI application must include a huge backend for a huge static binding.

Wrong, scripts calling package manager has to know meaning of bytes whether there is single or multiple binaries. Pacman has single binary and its ansible module is longer.

xbps packagekit have all ready been adressed:
https://github.com/pandom79/xbps/tree/packagekit

Approach used there is wrong and won't be merged. Some other PackageKit backend that calls binaries would still be useful.

For a TUI a static binding over a single entry point xbps will add stability, compare to bind multiple tools xbps-XYZ.

This seems to be main misunderstanding. xbps-* binaries interface is stable enough to use them from scripts.

There exist gui for xbps, octoxbps, that uses existing commands. It was created in 2016, then adjusted once in 2020 for how xbps-self updates (that single-entry would unlikely protect from), and continues to work fine.