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

Subject: Re: [boost] [BPM] Supporting an alternative to meta/libraries.json
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2016-01-06 14:50:48

Rene Rivera <grafikrobot <at> gmail.com> writes:

> 
> I should have prefaced all my replies with.. I don't feel strongly opposed
> to this change. Just more like "meh"  So please take my comments in that
> context.
> 
> On Tue, Jan 5, 2016 at 4:52 PM, Louis Dionne <ldionne.2 <at> gmail.com> wrote:
> 
> > [...]
> >
> > If there are other uses, could you please elaborate? This is not
> > rhetorical; such uses would point out other places that need to be 
> > changed to accommodate my proposal.
> >
> 
> I don't know all of them ATM. Daniel maintains some extra tools that deal
> with that file. So he will need to tell us.

Ok no problem. Let's hope Daniel sees this thread.

> > [...]
> >
> > If not confusing, it can definitely be surprising. The convention for
> > storing meta data and configuration data is to use dotfiles, not meta/ 
> > directories.
> >
> 
> It's a convention on Unix style systems. Not so much on Windows. For
> example, Appveyor doesn't use a dotfile (although maybe they support
> alternate names?)

That's true. However, I think that it would be better to adhere to a 
convention, even if not universal, than to adhere to no convention at all.

Also, you are correct in thinking that Appveyor allows customizing the name 
of the appveyor.yml file.

> > Also, my point is not only about confusion, but mostly about clutter. The
> > meta/
> > directory at the root of Hana appears in my editor, my file browser and
> > everywhere else as a directory. It is given the same priviledged place as
> > other directories such as include/, when it should be a mere detail.
> >
> 
> Personally I consider hiding of information (aka files) by IDEs to be a UI
> bug. Which is especially painful to me as I spend most of my personal
> programming time on OSX  It also means I had to dig around IDE
> documentation to disable that bug.

I guess this is personal preference, then. Outside of an IDE, I find it very 
useful to have commands like `ls` exclude dotfiles and dotdirs by default.
But again, you could argue for the contrary, so let's assume this is not a
strong argument for or against.

> [...]
>
> > Also, as a side note, I would probably oppose storing release notes in 
> > such a directory. Some libraries are also released on their own, and it 
> > would be messy to store Boost-specific release notes in there. Plus, some 
> > people might want to use GitHub to provide release notes (this is my case). 
> > And even if we were to always include release notes in a library, we could 
> > argue that using a CHANGELOG file or similar is more in line with existing 
> > practice.
> >
> 
> You are going to need to mention what goes into here <
> http://www.boost.org/users/history/version_1_60_0.html> somewhere. And I'd
> prefer to move away from having authors continually submit PRs to the
> website for this.

Ah, I see.

> [...]
> 
> > 2. Suggest using a .boost _directory_ instead of a single file
> >
> 
> Renaming the directory seems like a better choice to me.

In retrospect, it probably is a better choice indeed. The changes required
to existing tools would also be even more trivial, and we could easily do a 
batch renaming for all modules.

Like I said elsewhere, my problem is not file vs directory, but the way such 
a file or directory is named.

> > [...]
> >
> > What if Travis had decided to use a ci/ directory instead of a .travis.yml
> > file? Clearly, using Appveyor and Travis at the same time would have been
> > confusing, since both of them are CIs. Using .travis is just more focused,
> > and it carries the intent better.
> >
> 
> It's a case of facets. For CIs they are facets of a repository. Which is
> not really the case for Boost. It's single a Boost library. Now I grant you
> that it's becoming possible to have a library be independent and a Boost
> library. So perhaps that's the issue you are trying to resolve? I.e. How to
> manage a library that has both an independent, outside of Boost, existence
> and is part of Boost?

Yes, exactly. When reasonable, I want to minimize the cohesion between Hana 
and Boost. In its current state, Hana is a completely standalone library,
which also happens to work inside the Boost tree. I'd like it to stay that 
way, since I find it gives me more freedom to use Hana the way I want.

> > > > 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.
> >
> > As Glen suggested, we could also move all the modules to the dotfile
> > approach.
> > Otherwise, I think you can see from my pull requests that the amount of
> > added
> > maintenance is quite small.
> >
> 
> If we change.. I prefer to just move everything to the new way. Having
> multiple supported ways hasn't worked out so well for us in the past 
> And it's easier to deal with one way for tools (see my other post).

Sure, then I'd be OK with doing a batch rename.

> [...]
> 
> Right. You will definitely need help. At least to go in and merge all the
> PRs involved in this. Since only admins (aka the release team) has enough
> privileges to do this unilaterally. And it needs to be unilaterally, since
> the last time we did such a change (creating that meta dir) it was
> impossible to get authors to help.

If I provided a script to do it, could someone from the release team update
all the repositories? Such a script should be fairly simple to write, but in
comparison creating 100+ PRs and merging them would be quite cumbersome. One
problem I see is for those libraries maintained as forks; in this case the 
original repository would need to be updated, which would require authors
to cooperate. But I think all libraries maintained as forks have authors 
that are around, so it should be doable.

Regards,
Louis