Re: [boost] [modularization] Are modular releases a goal or a non-goal?

Subject: Re: [boost] [modularization] Are modular releases a goal or a non-goal?
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2014-09-18 05:18:30

On 09/18/2014 11:31 AM, Stephen Kelly wrote:
> Vladimir Prus wrote:
>
>>> Is something similar to this a goal or a non-goal for 'Boost
>>> modularization'?
>>
>> It looks that unless you, or somebody else, writes npm-for-c++, then the
>> huge amount of modules in Boost will make any such modular tarballs be a
>> disservice to users.
>
> A disservice to users? How so?

You have current situation - where users know to go a known place, download tarball,
and use it. What you're proposing is...

>
> There are several such npm-like things. The problem isn't choosing or
> writing one, but adoption. A prerequisite to it being operational is modular
> releases, so all you're doing is designing catch-22 situations for me to
> answer.

... to introduce yet another option, namely to pick some subset of 100 tarballs to
download, where a useful subset is often big, and where you don't appear to plan
any way to automate this right away.

So that seems like offering a users a fairly inconvenient, if not useless, way
to obtain Boost components, and so such choice seems more like trouble to me.

You can argue that an ultimate goal of running some tool with the name
of Boost components you want, and having those downloaded along with dependencies,
is a good goal (and there's a lot of reason to that) and that an infrastructure to
create per-component tarballs is important implementation part, but in itself,
having a bunch of tarballs somewhere on the web seems like a non-goal to me.

>
>> It's must easier to just close everything and remove
>> a couple of components that take up 90% of source size.
>
> Users have always had that option.
>
> What does 'boost modularization' introduce that's new for users? Why would
> anyone possibly get excited about the fact that static_assert is in a
> library of its own? How does that fact affect users of boost in any way?

I don't follow the logic of your questions. I'm not excited about static_assert being
a separate git repository, nor am I excited about prospect of having a separate
'release' thereof. And by saying "why would anyone possibly be excited" above you
appear to have the same view - while your earlier comments appear to suggest that
individual releases is a good thing. Could you spell out the final destination
you're after?

>> (Preemptive snarky comment: Qt does not need npm, since the number of
>> modules is relatively small, and many of them are truly optional)
>
> Tell me how the 'truly optional' phrase applies or does not apply to boost
> modules. It's not clear what comparison you're drawing here.

It applies in that many users can download Qt Core and Qt GUI, and don't
care about the rest. In case of Boost, pretty much any useful library
will pull a dozen others, and therefore asking the users to download
component tarballs becomes much less reasonable approach.

- Volodya