Tiny Core Base > TCB Talk

Suggestion to embrace the yaml format for .info files

(1/3) > >>

CardealRusso:
Hello. I would like to make a suggestion to start using the yaml format in .info. I personally have no experience with yaml, but I've found that it's the most similar to the current non-standard format and the change would be insignificant.

I'll use http://tinycorelinux.net/14.x/x86_64/tcz/cairo-dev.tcz.info as an example.

The only change would be the description and changelog, in case there are multiple lines.
There are two options:
1. Use a multi-line variable.
It would look like this:

--- Code: ---Change-log:|
            2012/11/09 first version
            2012/11/16 updated 1.10.2 -> 1.12.8
            2013/11/05 updated 1.12.8 -> 1.12.16
--- End code ---

Or array:

--- Code: ---Change-log:
            - 2012/11/09 first version
            - 2012/11/16 updated 1.10.2 -> 1.12.8
            - 2013/11/05 updated 1.12.8 -> 1.12.16
--- End code ---

Apparently using spaces or tabs makes no difference, as long as only one is used in a multiline/array variable (using tabs and spaces in the same variable would probably not be correct).

https://codebeautify.org/yaml-parser-online

mocore:
the (current) tcz.info format to meh appears more or less
like the http header format  *

- https://www.rfc-editor.org/rfc/rfc9110.html#name-message-context

with the exception of the multilline change-log field you mention




--- Quote from: CardealRusso on December 28, 2023, 12:42:48 PM --- suggestion to start using the yaml format in .info.
I personally have no experience with yaml, but I've found that it's the most similar to the current non-standard format

and the change would be insignificant.

--- End quote ---

>the change would be insignificant.
for who ? would it be so !?? i wander

if this is the case what advantage would this bring ?

or rather with what(language) and to what purpose are you trying to parse .info files ?
and
 consider using awk  ;) :P
i cant read the example info with out thinking up some methods to try and handle the multi-line Change-log field case tbh  ???

or perhaps for this case its possible * to modify on the fly *
eg  include ` sed -e's/Change-log:/Change-log:|/g ` this pipeline before processing tcz..info field ?


*( http header format ftr is also much like tiddlywiki's .tid files https://tiddlywiki.com/static/TiddlerFiles.html  )

CardealRusso:

--- Quote from: mocore on December 29, 2023, 03:05:52 AM --->the change would be insignificant.
for who ? would it be so !?? i wander

--- End quote ---
Hello. It wouldn't be necessary to adapt all the existing .info files, just the ones that have been updated.

--- Quote ---if this is the case what advantage would this bring ?

--- End quote ---
A standard, without too much effort.

--- Quote ---or rather with what(language) and to what purpose are you trying to parse .info files ?
and
 consider using awk  ;) :P

--- End quote ---
Actually, I'm not trying to parse the info, at least not now.

--- Quote ---or perhaps for this case its possible * to modify on the fly *
eg  include ` sed -e's/Change-log:/Change-log:|/g ` this pipeline before processing tcz..info field ?
--- End quote ---
I don't think it's that easy.
Your example didn't work, but if it did, it probably wouldn't return the same results in the next .info from a different author.

mocore:
hi CardealRusso
thanks for your reply / perspective

>Actually, I'm not trying to parse the info, at least not now.
in that case your subconscious  *is* piloting to write one while you are distracted  ;D

>I don't think it's that easy.
agreed
all though ... it appears the problem is less the "current non-standard format" and more "current non-standard format's"

if this is the case ( imho it appears so ) * see also : "repology-updater/issues/784# Tiny core linux  ~  https://forum.tinycorelinux.net/index.php/topic,26273.0.html "

or perhaps *even more* accurately
the problem is
the current info files are intended for human consumption as plain text
not for programmatic / machine readability & processing

the latter obviously implies "trying to parse the info"

 with this in mind
changing "description and changelog, in case there are multiple lines." the format
would (imho) only solve the problem for new/updated info files **
**assuming the *new* format was *somehow(by what process??!!)* enforced

that(imho)  in-effect would add one more *known format* to the potential options ....

which  reminds me of  submit-TCZ  script to help check for problems before sending extensions
 
... some *automated* method to identify the differences in format   of info files currently in the repo (that could then be considered as alternative format  or be corrected / standardized to a common format )
seams more likely to bring machine readability to info fles / the reop
 

gadget42:
xkcd ftw

https://xkcd.com/927/

Navigation

[0] Message Index

[#] Next page