Vladimir Prus wrote:
You have current situation - where users know to go a known place, download tarball, and use it. What you're proposing is...
I'm asking whether it's a goal or a non-goal. Not proposing it, as such.
... 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.
Of course I have no plan to automate it because I don't know if it's a goal or a non-goal (ie, would be accepted by boost or not).
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.
Whether it's useless depends on how many split tarballs there are and what they contain. There are many ways to split. The 'many small core libraries' could all be together for example. But don't get attached to details: I'm saying there are many ways to split.
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.
Do you follow logic of the question "What does 'boost modularization' introduce that's new for users?" ? Putting boost-static_assert in a library of it's own is part of modularizing boost, and I'm told it's a good thing that it's in a library of it's own. How would any 'good thing' from 'modularized boost' translate to 'a good thing' for users of boost? What is the 'user story' of modularized boost? Most users use the download link in boost.org, right? They don't use the git repos. What changes? Modularization of the git repos changes the 'developer story', but how does the 'user story' change?
Could you spell out the final destination you're after?
I'm trying to find out whether this thing is a goal or a non-goal, and if it is a non-goal, then is there a different 'user story' to aim for.
(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.
You can split boost any way that makes sense, if splitting is a goal. Thanks, Steve.