On Tue, 2018-11-06 at 23:36 -0600, Rene Rivera wrote:
> On Tue, Nov 6, 2018 at 4:05 AM Torvald Riegel <triegel_at_[hidden]> wrote:
>
> > On Tue, 2018-09-18 at 21:48 -0500, Rene Rivera wrote:
> > > On Mon, Sep 17, 2018 at 9:05 AM Rene Rivera <grafikrobot_at_[hidden]>
> > > wrote:
> > >
> > > > This is one of two papers I would like SG15 to consider for the
> > > > next
> > > > meeting.
> > > >
> > > > <
> > > >
> >
> > https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_Dx
> > > > xxx_R0.html
> > > > >
> > >
> > > I now have a paper number for this. And I've updated the page with
> > > that.
> > > You can read it here now:
> > >
> > > <
> > >
> >
> > https://rawgit.com/bfgroup/std_cpp/master/doc/package_ecosystem_plan_D1
> > 17
> > > 7R0.html
> > > >
> >
> > This is a very ambitious plan, and scope.
> >
>
> I don't think saying that we need APIs for our tools to interoperate
> ambitious. Yes, a whole package ecosystem is ambitious.

The tools should be fit for the ecosystem you want to target. With the
ecosystem being a complex topic, building proper tools for it will also be
complex.

> But that's where we
> are. We need to identify not just the scope of what we need to do. But
> also
> identify how to break it up into manageable parts.
>
> At least judging from this paper, I have concerns that this is
> approaching
> > the problem from the wrong angle. Specifically, it starts from the
> > perspective of what tools to use.
>
>
> It starts from the perspective of what tools we are currently using, i.e.
> existing practice.

When you say "we", which group do you mean? Are you sure that the existing
practice you see is representative for the industry as a whole, or large
parts of it?

>
> > That's the simpler part of a
> > tooling/dependency/marketplace ecosystem, and it's not the part one
> > should
> > start with IMO.
> >
>
> I'm confused.. is it a "very ambitious plan" or the "simpler part"? Those
> seems contradictory to me.

The paper seems to have ambitious plans, yet focuses on the simpler parts.
That's not a contradiction in my message, but instead a short-coming of the
approach IMO.

> The paper didn't make it clear to me what stages of a software lifecycle
> > you want to cover: Build only? Build with binary
> > dependencies? Testing?
> > Deployment? Deployment with a specific update/upgrade mechanism?
> >
>
> Correct, I don't talk about any of that, intentionally. Those should be
> aspects that additional papers defining the APIs and additional
> components
> should identify.

But those aspects are essential to understand what the goals are, and where
one should even start.

>
> > You seem to want to allow binaries in packages, so that brings in
> > deployment problems (at least for your build system) even if you're
> > just
> > intending to cover the build phase.
> >
>
> I'm sorry if that personal opinion is apparent in the proposal. But, yes,
> I
> believe that we should supports both source and binary packages. As
> binary
> packages are a requirement for my industry.

I don't have a strong opinion either way, but be aware that this makes the
problem more complex.

> The paper also doesn't cover the industry realities and business aspects
> > that one needs to consider when the target scope is an "ecosystem".
> > Vendors won't stop wanting to differentiate or control markets just
> > because
> > we create a C++ proposal.
> > For example, you write that it would be nice to have a single global
> > index.
> > I'd bet against this happening for any index of sufficiently large
> > relevance for the industry. Controlling the major index would mean
> > control
> > of access to the major marketplace for C++ packages -- which is
> > something
> > both vendors and regulators would happily fight over. One can't go to
> > Amazon and simply list something there under one's own terms; same at
> > Google Playstore, and all the other "marketplaces". Another example
> > even
> > more similar to the package index are registries for Linux Containers:
> > there are common interfaces for containers, but there are several
> > registries for both business and technical reasons.
>
>
> Indeed, I'm fairly certain this will be the hardest aspect to achieve.
> And
> I do suspect that in the end we will end up having to deal with multiple
> indices (for the simple reality tha
> t we need to supports non-public indices
> at least). If we do end up with multiple we will need to define how
> collisions should be handled (if at all). Yes, there are many questions
> to
> resolve when we define how the index should operate. But we can all
> hopefully agree that we need some index if we are to achieve the
> committee
> goal of introspecting the C++ ecosystem and the user goal of accessing
> the
> large collection of C++ libraries out there.

Perhaps a better way to understand what's even possible would be to discuss
which kinds of indices are possible under which sets of assumptions. And
this goes back to the ecosystem and software lifecycle questions.
For example, being able to standardize on a single index that's actually
useful is very unlikely because of the points I mentioned above. And if
the index is just like a more strictly formatted web search, it's not
really helpful.
Another example: There will be collisions in the sense that users of the
indices will be able to choose from more than one variant of some piece of
SW. Otherwise, there will be no competition, which would be bad.

Questions about tools arise only several steps later. First, the problem
scope should be clear, and it should be likely that there is *a* solution.
Then one can think about which tools would be useful.