Re: [BuildStream] How to synchronize nested junctions

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi all,

First, I'd like to just voice my support of the symbolic/pseudo
junction approach which is currently under discussion.

On Wed, 2019-04-10 at 17:57 +0200, Jürg Billeter wrote:
> Hi,
[...]
> > I see what you mean, I think the current behavior is to error out if
> > the refs do not match ?
>
> The current behavior is to use the ref (and subproject options) from
> the junction in the top-level project. If two subprojects have possibly
> conflicting junctions of the same name and the top-level project
> doesn't have a junction of the same name, BuildStream reports an error.
>
> (To be precise, the junction used for conflict resolution doesn't have
> to be in the top-level project, a common ancestor of the conflicting
> projects is sufficient.)

I think this is a bit reversed and I suggest changing this behavior so
that it is a configurable warning.

Rationale: My expectation when depending on a subproject is that I will
obtain exactly the artifacts from that project as I would, if I were to
build that project explicitly myself. 

I think that overriding a detail of my subproject implicitly in this
way, especially in a way the user might not expect or be aware of, is a
bad thing.

If I am project (A) and I depend on both (B) and (C), I might not be
aware that (B) one day also decides to depend on (C) - in this instance
I am no longer depending on (B)'s definition of (B), I am in fact
redefining what (B) is by overriding it's ref to (C).

I propose that (following the above example) we change this to be a
configurable warning, and that:

* If the ref and project options for (B)->(C) differ from the ref and
  project options for (A)->(C) in any way, then a warning is issued
  at build time, explaining that the ref and options declared
  for the (A)->(C) junction will override the ref and options declared
  for the (B)->(C) junction.

  I.e. a warning that (A) is redefining (B) by overriding it's junction
  to (C).

* If project (A) has configured this error to be fatal, that the
  warning be treated as fatal.

* If the project (B) has configured this error to be fatal, but not
  (A), then this error is not fatal.

  I.e. the configurable warning is:

    "Whether overriding a subproject's junction is acceptable"

  And not:

    "Whether having my junction overridden is acceptable"

> refs / subproject options of possibly conflicting junctions are not
> compared. I.e., even identical junctions in different subprojects are
> reported as error if the top-level project doesn't have a corresponding
> junction as well.

I presume that by toplevel, you mean highest level - for instance, if I
were to add a project (D) on top of the A, B, C example above, which
junctions into (A) - then (A) remains the highest level project with
any knowledge of (C), and as such there is no error.

Is my understanding correct ?

[...]
> > Maybe a good solution is to have a way to declare the junction such
> > that I should inherit the ref from the matching junctions in
> > subprojects ?
>
> I agree that it makes sense to allow configuring a junction such that
> it inherits ref and subproject options from a junction in a subproject.
> However, I think we should require explicitly specifying the name/path
> of that other junction, as per Chandan's first suggestion.
>
> I.e., I don't think BuildStream should attempt to figure out on its own
> which subproject's junction to use for ref and subproject options.

Also agree.

Cheers,
    -Tristan