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
> 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  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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk