Suggestion to embrace the yaml format for .info files

[DukeNukem]

Hi everyone,

Switching to YAML for .info files is an interesting idea. While the current format works well for its intended purpose, YAML could bring more consistency and make automated parsing easier for those who need it.

At the same time, it’s worth remembering that .info files are primarily for users installing extensions, so keeping things straightforward and easy to read should remain a priority. If a change is made, it would make sense to approach it gradually, allowing for compatibility with the existing format and ensuring smooth adoption.

[Sashank999]

Hello.

I'm not trying to add more fuel to this argument but I'm in support of using an actual, structured format for creating .tcz.info files. The improvements that immediately come to my mind:

- Easier evaluation of extension submission with submitqc - we can more easily check for missing fields and also add submission details. This can make the submission of updates for existing extensions easier (I myself can write a submitqc patch for fetching .tcz.{info, dep} files for a previous version and placing in the current folder so that you don't need to have them in place).
- Ability to change the rendering format of .info files in an easier way - Apps and tce currently display whatever text the files contains on the server. We can change the rendering format as we can separate the fields and values with proper separators. We can have the changelog listed in chronological order or have the latest change first.

As for the format itself, any format (except XML, please) does the work. CSV, JSON (the GOAT), JSONC, YAML and TOML are a few options that I currently think would work fine.

Moreover, with the alpha testing of TCL v16, I don't think there is no better time for thinking of such a change, if it is actually necessary.


P. S. I also sometimes think of why tce and tce-load are written as bash scripts and not in C (or Rust, for those rustlings). Perhaps there is some reason, such as having editable scripts even after OS boot. In that case, I think we can think of switching to Lua, which is fast and editable. But the main reason I think of switching is performance. Maybe it is a debate for another major release of TCL.

[nick65go]

@Sashank999: Not trying to be the devil's advocate, but regarding tce-load & co, I wish you good-luck... because you will not have 

The basic commands (like tce-load) should work even without extensions loaded, aka in virgin base. And this base does NOT have lua, neither rust etc. (even if LUA is small size). The actual AWK engine is inside busy-box so it is C compiled.

A bump in speed is if using C (compiled) for any/all ash scripts, but curaga does not want it.
Plus is easy to edit/change them on the fly (debugging).
Anyway, any perceived increase in speed MUST first be measured, and if is significant THEN estimate how often is used. (ex: an increase of 50% --keep dreaming -- used only 10% of time is 5%, not impressive). YMMV.

[mocore]

Ability to change the rendering format of .info files in an easier way

see also : "(tcz) info 2 JSON (the GOAT)" @ https://forum.tinycorelinux.net/index.php/topic,27554.0.html
*please test  

I don't think there is no better time for thinking

thunk is cheep ... show me the code ( also the data thnx )


*8 bit mario noises*

I got special powers (wow)
From eating precious flowers

* https://learnxinyminutes.com/awk/

[GNUser]

The basic commands (like tce-load) should work even without extensions loaded, aka in virgin base. And this base does NOT have lua

The lua interpreter is small (around 200 kB in size), so theoretically could be included in base system.

That being said, the TCL developers are (fortunately) very conservative. I wish I could bet that there will be no big changes to TCL's base system or package manager (not even to .info file format). Betting on this would be an easy way to get rich

[mocore]

The lua interpreter is small (around 200 kB in size), so theoretically could be included in base system.

perhaps with luainkernel/lunatik   "info 2 JSON" could be a module