Add wrapper for package manipulation

[dimitry-ishenko]

What do you guys think about abstracting away package installation and removal?

This will help add consistency and reduce boilerplate. Usage is as follows:

package install vim
package remove mc
package is-installed nmap
etc.

This will also replace check_if_installed and apt_install_wrapper commands.

[Tearran]

@dimitry-ishenko This could be use to consolidate and refine or replace some of the following. Your idea is a good.

configng/tools/modules/functions/check_if_installed.sh

Line 12 in 3740e7d

function check_if_installed() {

configng/tools/modules/functions/config_interface.sh

Line 428 in 3740e7d

see_current_apt() {

configng/tools/modules/system/apt_install_wrapper.sh

Line 13 in 3740e7d

function apt_install_wrapper() {

Reference for helper function naming standards,
I suggest

["module_packages,example"]="help install remove update upgrade check"

or

["set_packages,example"]="help install remove update upgrade check"

note
IMO, Seems the inconsistency more a matter of a defining a procedure to follow then automating and document it. This is difficult while the remains database is incomplete, Part of the database is json and part associative array . The module_option array is missing data points that exist in the json. That need to be added to all the module_options.

[dimitry-ishenko]

Thanks @Tearran. Are you suggesting to rename the file (ie, package.sh -> module_packages.sh) or also change the name of the function? I chose the name package because it makes the code natural and easy to read.

By the standard it would have to be something like:

get_package vim
rem_package mc
see_package_installed nmap

IMHO these are a bit less natural, but if that's what we gotta do, then that's what we gotta do.

[Tearran]

Just the function name the prefix is used to separate groups. So if this is a module use module_ if it's a helper to be used with a module see_ set_ even etc..

This I would consider both so your call but only one prefix name.

We can even refine and define new prefix to clarify things. We do have "generate_" , Perhaps, "helper_" "manage_".

[dimitry-ishenko]

Just the function name the prefix is used to separate groups. So if this is a module use module_ if it's a helper to be used with a module see_ set_ even etc..

This I would consider both so your call but only one prefix name.

We can even refine and define new prefix to clarify things. We do have "generate_" , Perhaps, "helper_" "manage_".

TBH none of the prefixes really fit here... How about adding a package_ or pkg_ prefix? Then we would have:

package_install foo
package_remove bar
package_is_installed baz

or

pkg_install foo
pkg_remove bar
pkg_is_installed baz

Please see 👇🏻

[Tearran]

package_ should work well. although IMO pkg_ fits the 3 letter prefix better, but that is unimportant ;)

would also suggest simply "check" or "status" for the is_installed.

package_install foo
package_remove bar
package_check baz

Quick fix : "Disabled" or ""

	["package_<job name>,status"]=""

If you don't mind helping refine module_option.
The module_option status, may be misleading as it is. Last check "Disabled" is the only string that is used.

Reference:

configng/tools/config-assemble.sh

Line 158 in 0a257fd

filter_disabled() {

&&

configng/tools/modules/functions/config_interface.sh

Line 107 in 0a257fd

done < <(echo "$json_data" | jq -r '.menu[] | '${parent_id:+".. | objects | select(.id==\"$parent_id\") | .sub[]? |"}' select(.status != "Disabled") | "\(.id)\n\(.description)\n\(.condition)"' || exit 1)

I think we can leverage this to define what the function is.

	["package_<job name>,status"]="Helper"

For modules it would be. System, Network, Localization, Software. and any other category that may be needed at later date.
#321 is about finishing the database then replace some slow bash parsing with JQ (json query).

[dimitry-ishenko]

package_ should work well. although IMO pkg_ fits the 3 letter prefix better, but that is unimportant ;)

Great idea, I will change it to pkg_.

[dimitry-ishenko]

If you don't mind helping refine module_option.
The module_option status, may be misleading as it is. Last check "Disabled" is the only string that is used.

I am still getting a feel for what does what, where and how 😃 but I can take a look.

[dimitry-ishenko]

@Tearran should I keep the name of the file as package.sh?

[Tearran]

no standard set, as for the logic it is inconsequential, so snakecase "any_name_will_do.sh"

configng/tools/config-assemble.sh

Line 26 in 0a257fd

function merge_modules(){

Software does set a president as it uses the prefix "install_"
If we want to follow this naming consistency IMO "helper_" would be appropriate for this new and existing helpers in functions folder for, naming conventions

[Tearran]

@dimitry-ishenko in short code wise currently it does not matter can leave it if you like. But :) this is a good place to clarify, and refine existing precedent for consistency.

tested all works with --api flag.
Seems like Non interactive UX so perhaps should be "interface_" for file prefix.

./bin/armbian-config --api package_install whiptail

precedent

https://github.com/armbian/configng/blob/main/tools/modules/functions/interface_menu.sh

Note : The [[ -t 0 ]] Does Not work with the --api option

[dimitry-ishenko]

This should be ready to go. Works in non-interactive mode as well.

I've opted for pkg_installed instead of pkg_check or pkg_status because "check" or "status" can mean many different things. For example, this reads like almost natural English:

if pkg_installed zfsutils-linux; then
    ...
fi

[dimitry-ishenko]

Note : The [[ -t 0 ]] Does Not work with the --api option

@Tearran currently there is no differentiation between the menu and the --api option. One thing we can do is close stdin when using --api and it will run without the UI:

"--api")
	shift
	if [[ -z "$1" || "$1" == "help" ]]; then
		see_use
		exit 0
	fi
	option="$1" 	shift
 	args=$(sanitize_input "$@")
 	# echo -e "\"$option\" \"$args\""
-	"$option" "$args"
+	"$option" "$args" <&-
 	exit 0
 	;;

[Tearran]

@igorpecovnik IMO nice improvements ready to go, any option?
@dimitry-ishenko amazing. even deprecated that like "pssst it was but a thing", lol NIce.

[igorpecovnik]

Sorry for tuning in late. I was busy in other segments those days ... Great work! I would remove function tools/modules/functions/check_if_installed.sh right away so we don't drag it along anymore if its not used.

[igorpecovnik]

I assume it was replaced everywhere - in this case, free to merge.

[dimitry-ishenko]

@igorpecovnik I've removed both deprecated functions, but it looks like I need another review before I can merge.

[Tearran]

@dimitry-ishenko would have pushed this but, Something in the Unit tests broke.

[igorpecovnik]

Something in the Unit tests broke.

It is fine now / usually unrelated. I am working to stabilize that it won't break for 3rd party reasons that much. You can probably re-run them too - if you select unit tests here in PR.