Re: [BuildStream] Proposal: Workspace related DX features & design

[William Salmon <will salmon codethink co uk>]

On 04/09/18 10:55, Tristan Van Berkom wrote:
> Hi all.
>
> First thanks a lot to William and Tom for taking the time to brainstorm
> this, and sorry that I've been so tied up that I could not yet
> participate, even though this is an important topic to me.
>
> I will make a comment or two on this initial email which I think have
> not been discussed yet, and then move on to replying to the end of the
> current thread.
>
> On Fri, 2018-08-24 at 13:06 +0100, William Salmon via BuildStream-list wrote:
> [...]
> >   Once a change has been developed in a workspace it would be
> > desirable to have an easy way to get this information into the respective
> > upstream/vcs (or even just locally for the projects consuming it); we think this
> > may need to expand the workspace API but not change any existing features e.g.
> > `bst workspace patch create` (or a documented patch/quilt workflow) or similar.
> This sounds like an interesting proposal but I think will not overlap
> with other bst CLI APIs, so let's leave this safely out of scope for
> the enhancements we already have to consider here.
I wounder if this will be key for getting more people using bst as a 
development tool vs integration tool, and will shoot up the priorities 
when *someone* starts using bst in anger..

However as for how to proceed I think we are in agreement hear.

> [...]
> > As we propose to land all the
> > CLI changes to `workspace open` command in one MR, we may need to land the
> > option before the feature is ready. In this case we will have bst issue a "not
> > implemented" error if the --use-cache option was used.
> Absolutely not.
>
> The addition of a flag will not be added to the CLI before it's
> supporting feature is actually implemented.
>
> If this must be considered as a part of the API proposal, then it is in
> design phase and the resulting design decisions must be captured in the
> corresponding issue report accordingly, in this case:
>
>    Opening a workspace with a cached build
>    https://gitlab.com/BuildStream/buildstream/issues/311
>
> Once this proposal / design is settled, it will be important to update
> any relevant issues with the design decisions reached, and ensure that
> we have relatively small / consumable tasks which we can roadmap and
> land easily enough; try to avoid planning for overly large merge
> requests.

I think I had miss understood the subtleties of your don't change the 
api more than once vs general good coding. Thank you for the clarification.

> Asides from that, the only part I see here that is contentious with
> other related features, is the ambiguity which arises from opening
> multiple workspaces in a single `bst` command.
>
> However note that if there is a "flag which effects how a workspace is
> opened", then there might be more than one flag to consider than just
> the `--cache/--no-cache` flag.
>
> So I think that rather than talking about `--cache/--no-cache`
> specifically here; we should be asking the question:
>
>    "When opening multiple workspaces, can we specify options for
>     each workspace being opened separately ?
>
>     Or must we specify a single set of options which apply to
>     every workspace being opened ?"
I spent quite a long time trying to work out if we could do this.

I was thinking about "options per argument"

I spent a while and I don't *think* click supports this so I think we 
are limited to options that act globally. Unless I have missed something 
about click or we want to do something really hacky in our use of click.

Please see the other thread for my attempt to get round this for 
workspace location however, as for using this patten for other options 
seem like a lot of work and confusion and i am not convinced you will 
all like my suggestion in the other thread anyway.