Re: [boost] [BPM] Supporting an alternative to meta/libraries.json

Subject: Re: [boost] [BPM] Supporting an alternative to meta/libraries.json
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2016-01-05 15:47:03

On Mon, Jan 4, 2016 at 12:46 PM, Louis Dionne <ldionne.2_at_[hidden]> wrote:

> Dear list,
>
> Currently, all Boost libraries are required to have a meta/libraries.json
> file
> at their root, which contains some meta-data describing the library. As I
> understand it, this meta-data is then used to generate the list of all

libraries with their description when a release is done.
>

That's one use.

> I find having such a directory at the root of every library annoying, since
> it clutters it. Furthermore, for metaprogramming libraries, the name can be
> slightly confusing since meta/ might be expected to contain something
> different.
>

1. I don't see how it can be confusing to have that dir.
2. Having other dirs other than the required ones would not be common. And
not something I would recommend.
3. The contents of the meta dir are not restricted to Boost. The
information in it could be used more generally.
4. We are likely going to add more data files to that dir for other uses.
For example it would be convenient to add release notes data in there.

I propose that we allow libraries to specify their metadata in a `.boost`
> file
> located at their root. Using a dotfile is the most common way of providing
> information for an external service (for example .travis.yml), and dotfiles
> are usually more discrete when viewing the project in an editor.
> Furthermore,
> making `boost` part of the filename is more descriptive.
>

I don't see the point. It's a Boost library. It's already has "Boost" in
the "name".

> I have submitted a pull request to BPM [1] adding the ability to fetch the
> meta
> data in a .boost file. The meta-data can still be provided in
> meta/libraries.json,
> so this should not affect existing libraries.
>

It would as it's more maintenance and confusion as to where to have that
data. And as was pointed out that's not the only consumer of that data.

> Related questions that we might want to consider:
>
> - Should it be .boost.json instead of .boost?
>

Meh.

- Perhaps we could store the meta-data for all the libraries in the same
>   place, and get rid of the individual meta-data files?
>

No. The point of having that dir in each library is to decentralize the
information so that it can be easily managed by the individual authors
instead of needing continual release manager intervention.

> - If this suggestion is accepted, is there more to modify than BPM?
>

Yes. There are other tools (website & release related) . And of course
documentation.

In summary, I'm against this as the perceived benefit is minimal compared
to the "implementation effort".

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail