[Task]: Clarifying, Naming conventions and use

[Tearran]

Task description

Many aspect of sorting into groups has been focused on the end-user. What can we clarify each file use for the developer?

The modules in software and have a install_ prefix the rest a mix of module_ default_ and others from the git wiki. https://github.com/armbian/configng/wiki/Standards

Context: The projected started with what was coined a so called "Helper functions" that grew to the so called "Module" that may or may not utilise the "Helper functions", " Wrappers" , or other general or undefined groups the categories that do exist are end-user specific.

If we want to category the modules for the end-user we only need mirror the parent directory name in lower case or not at all as far as the projects code is concerned. software_ would seem the goto.

Otherwise what groups of code do we need to clarify as we do with install_ as it can clearly be defined and identified as 3rd party software management.

Perhaps it is time to set a limitation here and define them for consistency or continue to its close enough and works.

• install_ - instal and remove 3rd party `applications'
• default_ - Unknown
• module_ - A template file to show module use (what is a module_ a file or function)
• generate_ - module/helper to parse data and or output readable output for echo and or pipeline

[dimitry-ishenko]

@Tearran sorry I still don't quite follow where these prefixes would apply... Could you give me a concrete example of how this would apply, for instance, to the srv_* and pkg_* PRs that I've submitted?

[dimitry-ishenko]

IMHO helper_ and wrapper_ prefixes are not very useful, because pretty much anything can be classified as a helper or a wrapper for something else. At the end of the day, we are dealing with 1s and 0s so every bit of code can be called a helper or a wrapper to generate 1s and 0s. 🤣

Also, I would propose to group things by subject instead of action.

So, it would be package_ or pkg_ to deal with the subject of packages. And, service_ or srv_ to deal with the subject of services.

Instead of install_ for example, to deal with the action of installation. You can install packages, services, files, operating systems, shower heads, puppet governments, etc. which don't all necessarily belong in the same class.

Unless, again, I am not fully understanding what you want to accomplish... Sorry, I am a slow learner, but once I get going there is no stopping of me. It's in my blood. 😃

[Tearran]

The concept is to distinguish between modules and helpers.

Modules: Standalone, user-facing features grouped by subject (e.g., software, networking). These can be added or removed without breaking anything. With exception at current the manually edited job.json

Helpers: Reusable functions essential for multiple modules, grouped by action. Removing them breaks functionality.

The structure relies on folder names and file names as data points for parsing and nesting into production files. Modules are designed for flexibility, while helpers provide shared functionality across the system.

The goal is to refine how we identify and group these components while ensuring modularity and scalability.

I am suggesting
Modules functions full name_
helper functions abv_ name

modules can be sorted #321 , helper are not. Would it benefit to short the helpers? Resent talks seem to indicate this is the case.

[dimitry-ishenko]

@Tearran Ah. OK that makes more sense. So, what I did with the pkg_ and srv_ functions should be good then. 🎉