Re: [BuildStream] How to synchronize nested junctions

[Jürg Billeter <j bitron ch>]

Hi Chandan,

On Wed, 2019-04-10 at 19:18 +0100, Chandan Singh wrote:
> I agree that explicit is better than implicit in this case.
>
> Since we seem to be leaning in the direction of the first option I proposed, I
> think it would be good to agree on how we want to introduce this feature as it
> can be potentially confusing to users.
>
> I was thinking about adding a configuration option to the `junction` element
> that will be called something like `element`. When that is specified,
> BuildStream should try to load the sub-sub-project specified by that element
> instead of returning the sub-project itself.
>
> To continue our example, I think the junction for [base-sdk] in the
> [user-land apps] project would look something like:
>
>     kind: junction
>
>     sources:
>     - kind: git              # this kind is irrelevant for this example
>       url: url-of-core-libs  # note that this refers to core-libs, not base-sdk
>       ref: ...
>
>     config:
>       element: junctions/base-sdk.bst    # this is the new magic being proposed

I was rather expecting the 'pseudo' junction not to have any sources
but rely on another junction for [core-libs]. Otherwise you'd need to
synchronize the [core-libs] ref in core-libs.bst and base-sdk.bst
(would be in the same project but still).

Also, where would you specify options for the [core-libs] subproject?
junctions/base-sdk.bst in [core-libs] might have conditionals or
variables that are controlled by [core-libs] project options. They
would probably also have to specified in the junction file above but
that could be confusing.

Do you see an issue with skipping sources and specifying something like
'core-libs.bst:junctions/base-sdk.bst' in the above junction file as
target instead?

Maybe it would make sense to generalize this and define a new element
kind that acts as symbolic link / alias of another element. And that
could work for both junctions and regular elements.

Not sure whether this will be very useful for regular elements. It
could be interesting for situations where multiple implementations
exist for the same API and you don't want to specify a particular
implementation in each reverse dependency (similar use case as Debian
virtual packages). This can easily be emulated with a stack element
with a single dependency, but that approach doesn't work for junctions.

Cheers,
Jürg