Moving away from a single markdown file?

[kud1ing]

Since the Markdown file has grown a bit, i am considering extracting the data to a file (maybe JSON) and generating HTML from it.

Disadvantages:

• there is an additonal generator step
• contributors might expect a Markdown file

Advantages:

• the data file could be reused easier by other projects
• entries can show up in multiple sections without duplicating data
• less boilerplate code for contributors, less possibilities for errors
• the data can be checked and enriched easier. E.g. a script could check whether the links in the data file are correct or whether projects have (now) working Travis/Cargo URLs
• no manual sorting necessary anymore
• consistent output format across all entries
• the output format can be adjusted easier in the generator

[suhr]

See https://rust.libhunt.com/

[kud1ing]

@suhr As i see it, submitting data there is a one way street. I am fine with people doing that, it's just not for me (unrelated bad experience in the past).

[jeffparsons]

I heartily support this move. One application I'd be keen on would be tagging of projects paired with (client-side) search.

[Anachron]

I hate JSON with a passion. Maybe it is because it cannot have comments?

I suggest using something like TOML instead.

[cetra3]

How about you use my tool to combine them:

https://github.com/cetra3/mdcollate

[kud1ing]

@Anachron I am not a huge fan of JSON either, but my aversion for external code dependencies is greater. ;( Many scripting languages have built-in support for JSON.

[hauleth]

For human readable format I would prefer YAML over JSON as is more flexible and easier to parse by wetware.

[Limeth]

There are human-readable derivates of JSON. One of them is called HOCON, IIRC.

[hauleth]

But why not use human-readable JSON superset - YAML?

Łukasz Niemier
lukasz@niemier.pl

Wiadomość napisana przez Jakub Hlusička notifications@github.com w dniu 12.08.2016, o godz. 20:28:

There are human-readable derivates of JSON. One of them is called HOCON, IIRC.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #190 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AARzN39JU0Wa9q_xRYTuZCfcG9mYyTFLks5qfLtkgaJpZM4Ji2Zj.

[suhr]

@Anachron Do you hate JSON5 too?

PS: still, better to use TOML since it's much more popular.

@hauleth YAML is overengineered.

[Qard]

I think this bikeshed should be painted blue.

Seriously though, the storage format is irrelevant. The issue is not about which storage format is superior, it's about whether the content of this repo should be accessible as data and used to generate human-consumable pages.

Personally, I don't feel like there's a lot of value to content as data for this repo. Seems to me like the effort of building a generator and converting the existing content would far outweigh the small advantage of avoiding data duplication and sorting.

As a side note, there are already tools for validating links in markdown files, so you could just use those.

Personally, I'd rather just see the single markdown file split into multiple markdown files.

[pravic]

http://awesome-python.com for example. It is a single file too, but with TOC on left side.

[nasa42]

Would the format of libs.rs be an acceptable replacement? This is basically just bunch of TOML files - https://github.com/nasa42/libs.rs/tree/master/categories (and some scripts to generate HTML files periodically).

@kud1ing happy to give you access to the libs.rs repository.