Subject: Re: [boost] [BPM] Supporting an alternative to meta/libraries.json
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-01-05 20:21:29
Andrey Semashev <andrey.semashev <at> gmail.com> writes:
> On Wed, Jan 6, 2016 at 1:52 AM, Louis Dionne <ldionne.2 <at> gmail.com> wrote:
> > In summary,
> > 1. Using dotfiles allows other tools to see this meta information as it is,
> > and to deal with it properly.
> I don't see how using dofiles, dotdirs or regular directories affect
> tools. AFAIU, tools are able to access dotfiles/dotdirs the same way
> they're accessing meta/libraries.json now.
Of course they're able to access them in the same way, but they don't display
them in the same way. For example, in my editor, dotfiles appear at the top of
the file list. In the Finder, they don't appear at all. I've seen some editors
where they are greyed out. On the other hand, the meta/ directory appears as a
normal directory, which is annoying.
Of course, it's an annoyance we can cope with. But since I'm ready to do the
work, and since it impacts virtually nothing (my PRs are backward compatible),
why not just go for it?
> > 2. Using dotfiles sticks to a well-established convention for storing meta
> > data in a non-intrusive way:
> > Travis => .travis.yml
> > Git => .git, .gitignore, .gitmodules, ...
> > Bash => .bashrc, .bash_profile, .bash_history, ...
> > Hg => .hgignore
> > Rbenv => .rbenv
> > LLDB => .lldb
> FWIW, I hate that some of the examples above spur a bunch of dotfiles
> in my home directory or local copy of a repository or whatever. I
> would very much prefer if we had a directory with these files, and
> possibly not store all sorts of unrelated metadata in a single JSON
> file. I have no preference on how this directory is named.
Fine, it would have been better if the whole world had agreed on storing
metadata in a meta/ directory in the first place, and if tools had been
developped to understand that meta/ is not a directory like the rest.
Unfortunately, this is not the case right now, and my opinion is that
we should stick to the current common practice instead of diverging for
virtually no good reason.
If you are worried about not being able to store all you want in a single
JSON file, then let's go for a .boost directory with multiple files in it.
I don't care, as long as that dotdir
(1) does not clutter my folder list
(2) has a name that _clearly_ relates to boost, and that is hence unsurprising
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk