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.

[hippi777]

i also wondered much about a single binary

i guess it would become smaller, as the now-individual binaries probably share a lot that the compiler can reduce, but i'm not really familiar with their internals, like what libxbps contains, which tools use them and what is beyond it in the individual binaries, and how much they would collide?

my case is that i always want to write a space there... :D but writing a wrapper would take away completion, which is something i never played with so far, even if i read the common code in bashcompletion, and even if i think i could copy/modify existing things...

manpages and tests would be aligned too, so maybe it is a bigger work than any of us would have enough free time for, but otherwise, as a process, it could have a smooth transition step-by-step, like having a symlink in place of the current binaries when they become replaced... just for the record, cryptsetup solved the issue of their too lengthy man page, but the implementation isn't that pretty, and xbps doesn't have that much docs...

the way of using xbps is a distinct question i think, as gui/tui frontends should rely on cli/lib, instead of bloating the base...

(the installer could also be decoupled, but i still work on my own, so i don't really care, and yes, you still shouldn't expect any time when i will be ready :D i always do so many things in parallel... otherwise the goal of such is more about having a potentially unattended cli, than isolation for the rest at the level of files, either with default secrets to be changed after an install or with gocryptfs/tmpfs/whatever storage for them, but tmpfs shouldn't be used like so without encrypted swap...)

just slightly related, but what i really wish for is some more machine-friendly output, like json, or anything (i'm not a fan of it, what i would opt for is not really a popular choice, but i have a bigger amount of work around serialized lua tables, but nowadays i use shell for everything, and there is jq for json, which is kinda sophisticated...)

an option for disabling terminal magic made by xbps to trim long lines to the length of the terminal could be nice, as now i need to xbps-query -Rs $pack | tee often, and editing $pack in it takes more keypresses than it would with an option... i guess i will write a function for this soon enough, maybe i will even take the name xbps (without dash) for it, but then i arrive back to the (minor) problem of completion, otherwise it would be totally fine, and i would even think it is a nice feature that we have that name free, but xbps-query(){ $(which xbps-query) "$@" | tee;} (edit: no, this doesn't work) could work as well, just then the disabled trimming isn't optional, or otherwise it becomes more involved... just for the record, an underscore in place of the dash is an option for random hacking as well...

some nonimportant footnotes:
exec "xbps-$@" does the same

apt gave me cancer with its termio magic, it could fully screw up the text on my terminal and iirc there were some fast output that i always missed cuz it, and it is dumb for the tty detection that xbps does... i've read somewhere way back in time that apt-get is depricated, hopefully it still exists, but what i really hope for is that i will move my visionfive 1.0 to alpine from ubuntu sooner than later, as that's already 1 step closer to see void on it one day :D