Command Line Interface - Refactor

[DLopezJr]

This thread is for discussion on refactoring the cli.

The conversation started in an Github Issue: [LINK]

Topics to discuss

• Wrapping everything into a Main function
  • This allows someone to understand the flow quickly.
• Porting from bash to POSIX sh
  • Increased speed and portability
• If necessary breaking the single script file into many source files
  • With m4 macros, you can imitate a C style header workflow.
    • This allows breaking the codebase up into multiple files with the ability to concatenate them into one file for installation.

[ivan-hc]

Wrapping everything into a Main function
This allows someone to understand the flow quickly.

and someone other have difficults to understand, like me. Just to give you an example, when I had to convert JuNest into a portable solution to create ArchImages, I had several difficults to guess what to change in the codebase until i used the inbuilt Proot (not the best solution to made web browsers working without any difficult... and I'm still learning). The best way to take advantage of Junest is to use it with "namespaces", but it requires writing things in the $HOME, and an AppImage is a read-only filesystem. It's a pain in the ass.

Porting from bash to POSIX sh
Increased speed and portability

OK

If necessary breaking the single script file into many source files
With m4 macros, you can imitate a C style header workflow.
This allows breaking the codebase up into multiple files with the ability to concatenate them into one file for installation.

See the example of JuNest I've just talked above. For me having one bash script is easier to handle. In partivular when jou use the script in "AppMan" mode you can drag/drop it everywhere because everything it needs is in one place (apart the configuration file).

[ivan-hc]

Not to mention I'm working on new features, like "sandboxing" (see here). Thinking about rebuilding the code in another form would slow down my workflow, and quite a bit.

Then these ideas come to me suddenly, in the last 24 hours alone I have released 3 major releases of AM/AppMan in which I have unified the code (5), supported immutable Linux distributions (5.1) and lightened dependency policies (5.2 ). The next one will have sandboxing (5.3).

[DLopezJr]

I can understand the value of staying in the development headspace. Maybe we should add two branches to the repo?

• dev
• refactor

That way we don't slow you down and I can start experimenting with the refactor and you can check it out.

[ivan-hc]

Done:

• https://github.com/ivan-hc/AM-Application-Manager/tree/dev
• https://github.com/ivan-hc/AM-Application-Manager/tree/refactor

[ivan-hc]

@DLopezJr I've started refactoring by myself using functions (for now just they are only 3), I'm working to reducing the code more, as you suggested.

[DLopezJr]

That's excellent! You're more qualified to name the functions than I am. I'm busy with work/holiday right now, but I will be able to help out in Jan.

[ivan-hc]

I'm busy with work

Nice to read that (I'm unemployed).

You're more qualified to name the functions than I am

That's not true, I've understand that it is sufficient to add a suffix at the begin to made the developer aware of the option that uses that (for example _install_something or _template_something).

However, its thank to you if I have a new style of coding, I write code just for fun, I'm not a professional developer (and not a developer at all).

I'm busy with [...] holiday right now, but I will be able to help out in Jan.

So happy holiday to you and your family 😄