Re: [BuildStream] Summary of the 'Staging multiple elements in bst shell' discussion at the gathering

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

Hi James,

Thanks for clarifying, for me and for posterity :)

On Mon, 2019-02-11 at 12:03 +0000, James Ennis wrote:
> Hi Tristan,
[...]
> Yes, and as mentioned above, this is the element for which we stage the
> sources. However, for the additional elements, which will be staged as
> extra runtime dependencies, it was discussed at the gathering that we
> would stage these separately by 'merging the extra runtime tree'.

I see, I guess this means to extract any non-overlapping dependencies
from the extra elements and stage them "on top" so to speak ?

It could alternatively be to stage everything as if there were one
virtual top-level target which depends on all targets which need
staging (which might be slightly more straight forward for our
codebase), but I don't currently have any preference or opinion on what
this "merge" semantics should do either way (of course this should be
clear in any documenting materials).

[...]
> > Further, we should recognize that this is not specific to build shells,
> > the environment variables specified by a given target element will also
> > be the ones used for a regular `bst shell` which you might use to
> > launch and test a graphical application on your laptop.
>
> Ahh, this was not really discussed at the gathering. However, for a 
> 'normal' shell, the current implementation (in !909 [0]) is to merge 
> environment variables from all specified elements. Which may not be the 
> best idea due to possible conflicts. Perhaps there needs to be further 
> discussion as to what the right behaviour is here.
>
> To give my opinion on the issue, regarding the build shell, we're in 
> agreement that the build shell can only specify one target element, and 
> from what we've discussed, it does not look like we want to merge any of 
> the 'extra' environment variables from the additional runtimes here.
> So perhaps, for the runtime shell, we should try to be consistent and go 
> for a main target element, of which, we only merge its environment 
> variables.

I tend to also think that merging of environment variable dictionaries
depending on staging order etc is quite a bad idea and will probably
just lead to undesired surprises, and tend to agree we should probably
have a consistent CLI to select the primary target separately from any
additional dependencies for this purpose, regardless of whether the
`--build` option was specified.

[...]
> The use of the `--directory` option was not discussed at this gathering 
> but I agree that this could be a useful alternative.

Sure, it came up on list along with some ideas of supporting direct
staging of docker images or tarballs etc, but I think we can safely
consider this as an entirely separate feature (even if it may satisfy
similar requirements).

Cheers,
    -Tristan