Simplify repos.json

[mweidling]

:warning: This PR depends on #7.

This PR simplifies the repos.json file by including only the information we (currently) need. This makes parsing the file easier and saves resources.

The JSON now has the following structure (example: ocrd_typegroups_classifier):

{
    "additional_info": {
        "links": {
            "Dockerfile": null,
            "README.md": "https://github.com/OCR-D/ocrd_typegroups_classifier/blob/master/README.md",
            "ocrd-tool.json": "https://github.com/OCR-D/ocrd_typegroups_classifier/blob/master/ocrd-tool.json",
            "setup.py": "https://github.com/OCR-D/ocrd_typegroups_classifier/blob/master/setup.py"
        }
    },
    "compliant_cli": true,
    "id": "ocrd_typegroups_classifier",
    "latest_version": "v0.3.0",
    "ocrd_tool_json_valid": true,
    "official": true,
    "project_type": "python",
    "url": "https://github.com/OCR-D/ocrd_typegroups_classifier"
}

Missing information can be added at a later stage, of course.

[mweidling]

@paulpestov The general structure of the JSON file is set. Are you okay with it?

[paulpestov]

May I suggest some rough base strcuture for a project item (repo):

{
    "id": "cor-csv-ann",
    "name": "Full name of the project",
    "url": "https://github.com/ASVLeipzig/cor-asv-fst",
    "latest_version": "1.2.3",
    "unreleased_changes": 0, 
    "ocrd_tool_json_valid": true,
    "project_type": "python",
    "additional_info": {
        "description": "Small description text here.",
        "links": {
            "README": "https://github.com/ASVLeipzig/cor-asv-fst/blob/master/README.md",
            "CHANGELOG": "https://github.com/ASVLeipzig/cor-asv-fst/blob/master/CHANGELOG.md" 
        }
    },
   "conflicts": []
}

This would be the minimum amount of data that we weould need to display the mockup. I changed my mind a bit about the statuses. If you remember from our previous talk I thought it would be a good idea to have a statusesarray like:

{
    "statuses": [
       {
         "id": "ocrd_tool_json_valid",
         "value": 1,
       }
    ]
}

But now I think this is too strict and not very flexible, so maybe it's better (like you have it right now) to have certain keys on the item object that the frontend can take and interpret a certain status message out it. In case of released/unreleased changes the rule for the frontend would be: check unreleased_changes value, if 0 take the latest_version for example.

[mweidling]

Thanks for your feedback! A few thoughts:

• id and name are basically the same in the current approach, so I'd head for id
• what is the exact use case for description? Getting this requires an addition call to GitHub's REST API which I'd like to avoid if not necessary