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

Subject: Re: [boost] [BPM] Supporting an alternative to meta/libraries.json
From: Daniel James (dnljms_at_[hidden])
Date: 2016-01-13 16:05:07

On 13 January 2016 at 15:49, Louis Dionne <ldionne.2_at_[hidden]> wrote:
>> > Ok no problem. Let's hope Daniel sees this thread.
>> >
>>
>> We'll probably need to start another thread so he notices.
>
> I sent him a private email to notify him of the thread.

I think this is a bad idea, the advantages of such a change are
smaller than the disruption it would cause. Having two different
locations would be an issue, because it would be likely that people
won't realise that they have to deal with that - especially if one
location is hidden. So if someone writes a script using this data,
they'd miss some of it. The alternative is to move the files in every
module, which would result in a pointless discontinuity.

It's also not true that dotfiles are idiomatic here. Since you were
addressing package management, that's a fairly good place to look for
examples. I had a look at package management systems for several
languages (maven for java, nuget for c#, gopm for go, cpan for perl,
npm for javascript, composer for php, pip for python, gems for ruby)
and only gopm uses dotfiles. That's hardly an established idiom.

But I don't really think a third party tool is an appropriate place to
look. This is dealing with a boost specific problem, and has no
ambition to be a general purpose tool. The 'meta' directory is
intended to be part of the standard boost directory layout, and
follows the established style.

Of course dotfiles also don't have any special meaning on windows, and
many of our developers are windows based, so they'd just be weird for
them. And on platforms where they are hidden, that's a problem, as
they're not discoverable. The whole point of these files is to make it
easy for maintainers to update information, even if they don't know
about the system in advance. This is also the reason why the file
needs to be short.

I find the suggestion that the file's path should have had a boost
specific element more convincing, and if that had been suggested when
I was first setting this up, I would have changed it. But I feel it's
too late now, at this point stability is more important, and a path
collision with another tool/service seems very unlikely.

FWIW none of my scripts actually require a module to have this file,
the data can be managed directly in the website. I created them using
pull requests with a note saying that they weren't required. But
others wanted them to be in every module, so that's why it's required
now. And since you were wondering why it's a directory, there was a
vague plan to use a similar mechanism for the expected test results,
but no one has been keen enough to actually implement it.