A simple converter complexly

[Tearran]

Description

Converted to markdown and bash simulating nasting array.Proof of consept

Jira reference number [AR-9999]

Documentation summary for feature / change

Please delete this section if entry to main documentation is not needed.

If documentation entry is predicted, please provide key elements for further implementation into main documentation and set label to "Needs Documentation". You are welcome to open a PR to documentation or you can leave following information for technical writer:

• A simple converter complexly
• Will Turn your Json to a Bash simulated array and provide a table of features.
• ./build/doc/doc.sh

How Has This Been Tested?

• (Create armbian-build #5734
• (Armbian Build Framework Script [DOC-1] #5894

Checklist:

Please delete options that are not relevant.

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

[igorpecovnik]

I like it this way.

Do we have an agreement on:

• JSON structure. Does proposed structure covers all of our needs?
• Are we ready to start working on data? As I understand we need this list / db first, then adding bits of actual documentation to it.
• IMO we should merge .JSON (and those utils) at around 80% of the data competition.
• keeping deprecated options marked as deprecated in the JSON or not?

@didierjoomun @rpardini @EvilOlaf @TRSx80

[SteeManMI]

If I am following this topic correctly, I think the current state of the proposal is to have the json in the build git tree be the source of truth for the documentation. What gets put into docs would simply be generated from the json data.
This implies that developers in their PRs should adjust the doc json accordingly for new/changed features. Devs would not be responsible for final wording however, and that others (doc/technical writers/etc) will afterwards submit PRs to make what the devs originally submit be more readable/clear/better written/etc.

[rpardini]

I think the principle is more or less established, but

• The JSON contents are still very wrong. BUILD_ONLY does not exist, etc. Let's begin with stuff that exists.
• The JSON contents must be organized by CLI command, and not just floating "options" -- options vary by command.
• The bash code generated is not really usable in lib/. It needs to be, otherwise, this JSON will again just be another thing to remember to update
• The bash code generator... is a bit unwieldy. Really, lets use a proper parser and a language that allows us to do what we need to, instead of wrestling bash. (says the main bash wrestler here)
• Just my personal preference: let's use YAML, which allows for comments & references, otherwise we'll be duplicating stuff all the time.

[EvilOlaf]

The JSON contents are still very wrong. BUILD_ONLY does not exist, etc. Let's begin with stuff that exists.

Might be the case, however the first step is to have an agreement about the overall structure. Once this exists it can be filled with the correct data :)

keeping deprecated options marked as deprecated in the JSON or not?
I vote for keep as long as there is a way to comment on how this is being replaced, superseeded or whatever.

In terms of structure base I don't have an opinion. My knowledge in both are very basic to say the least.

[igorpecovnik]

The JSON contents are still very wrong. BUILD_ONLY does not exist, etc. Let's begin with stuff that exists.

I think keeping deprecated was brought up and reasoned at one of the meetings. I agree that we should focus on what works and not on what doesn't anymore, but we should at least think to have this and design accordingly.

@didierjoomun

The JSON contents must be organized by CLI command, and not just floating "options" -- options vary by command.

@Tearran

The bash code generated is not really usable in lib/. It needs to be, otherwise, this JSON will again just be another thing to remember to update

Better to keep only what is really needed. We can add later if we need this. I would also say we drop that out.
@Tearran

Just my personal preference: let's use YAML, which allows for comments & references, otherwise we'll be duplicating stuff all the time.

I support we switch to YAML. Its machine readable, we use YAML in many other ways and is closer to humans then JSON. Do we have some parsing structures or @Tearran needs to put something together?

[Tearran]

@EvilOlaf can you suggest something that may help motivate you me or other to make input change to the DATA manulay while we developed and simulated. atomate process?

I did try a Proof of concept, form. html page with little interest. https://armbian.tech/apps/configng.edit.html

@SteeManMI great interpretations with a couple of point to note.
This implies that developers in their PRs should adjust the doc json accordingly for new/changed features. at this point YES. with options for different preferred formats. DO you have preference if you were say offer an update to the infamous BUILD_ONLY could you suggest what if change to the data? how it may be presentint

Devs would not be responsible for final wording however, and that others (doc/technical writers/etc) I assuming it is community responsibility in general?

@igorpecovnik @rpardini I hopful showed a interpretation in #6389 (comment) YAML No Problem when the data is up to date perhap

[Tearran]

@rpardini