FR: Non-HTML index format for machine consumption (JSON?)

[kentfredric]

I've been musing over writing a general CLI interface to this website, but my main hurdle seems to be enumerating the end-points, as presently, my only option is 🤮 parsing HTML 🤮

A good start would be a file in /results/ like "index.json", which could at least give a list of repos like:

[
   {     
         "name": "gentoo",
         "description": "Gentoo Main Repo",
         "repo_url": "https://github.com/gentoo/gentoo",
   },
   { "name": "kde", ... },
   ...
]

The data-format for each sub-layer though still has to be worked out. Just the "list of repos that are tracked" seems more likely to be an arbitrary thing than what checks are available, and thus, much harder to encode in software.

But ideally I want to be able to do something like:

# gqa_l9 repos
gentoo
kde
pentoo
rust
science
# gqa_l9 repos --verbose
gentoo - Gentoo Main Repo : https://github.com/gentoo/gentoo

I think ideally, this file could be constructed in such a way that the main html page is generated from it, which makes your ability to ensure consistency is a little better.

I've intentionally left out any hints of references to deeper, similarly useful data structures due to not really knowing how they should look yet, and the the initial goal here is to be able to ingest the content shown on the HTML page, without needing an HTML parser, and presently loading data from those directories is an exercise for the consumer, where the only inferrable data is the "name" element, which must map to the /results/REPONAME/ stuff.

[kentfredric]

Also, to be clear, I'm not aiming to consume any filtered or sorted end-points, as those are mainly conveniences for people using the browser interface, I'll just be consuming the bulk files and implementing sorting/filtering client side, mostly because that's more flexible and powerful.

[mm1ke]

Actually that sound fun :)
Never though about exporting the results into something like json, but i like that idea.
I'm going to see what i can do here, but especially a repo list shouldn't be hard to create.

[kentfredric]

Hhm, though I'd admit having the results themselves available in json would have its benefits for parsing simplicity, keeping the existing formats is also good ( better space utilization and more friendly to generic tooling )