Re: [boost] Library list generated from meta/libraries.json files

Subject: Re: [boost] Library list generated from meta/libraries.json files
From: Daniel James (dnljms_at_[hidden])
Date: 2015-01-05 13:22:32

On 5 January 2015 at 17:38, Peter Dimov <lists_at_[hidden]> wrote:
>
> Yes, I knew about this file. I'm not sure, however, what is the point of the
> pre-library meta/libraries.json files then, as they contain (a subset of)
> the same information.

It's so that this data can be managed by the library maintainers.
Currently I have to do quite a lot of admin just to add a new library
or change the details. And people don't realise they have to let me
know when something has changed. Often the first time I would realise
is when someone complains after the release.

Eventually I want to also generate libs/libraries.htm and
lib/maintainers.txt from it. I really should get round to doing that
soon-ish, it's pretty awkward that it's part of the website.

> I had assumed that we'll be transitioning away from centrally stored files,
> and will be generating everything from the individual modules themselves.
> So, under that assumption, I expected the info in libraries.xml to be moved
> to the appropriate meta/libraries.json files, and then disappear.

Maybe, but I never envisioned this as a full solution. If we have a
full package system, it might want to use a different file format.
When I set this up, it looked quite likely that it would be based on a
third party system that would use something completely different, or
that the implementer would want to design their own file format.

I also didn't want to force it on anyone, anyone who didn't accept my
pull-request would be very unlikely to keep the file up to date.

>> Historical data is handled centrally, so it would be redundant and error
>> prone to store it in the library repos (e.g. if a library was pulled from a
>> release, but wasn't updated accordingly).
>
>
> Right... but what is the point of the json files then?

Answered earlier. I'm not sure why a package manager would need to
know when a library was first released.

> Wait, I think I figured it out... the release script generates (would
> generate) the release-specific info from the json files, then puts (would
> put) that into libraries.xml?

Sort of, it can also be updated from the beta and master branches.

> But I see how this might create a problem for the script that generates
> libraries.xml, and I also see why we can no longer change "workarounds" to
> "Workarounds" for consistency.

Could make it case insensitive. It probably should be.

> A compromise might be to add category_name: [] to the json files and keep
> the current category: [] as is. Or, I could just hardcode the names and be
> done with it. :-)

It shouldn't be too hard to automatically update the names, or add
them as part of the release process.