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

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

Hi Angelos,

On Thu, 2018-09-06 at 19:41 +0100, Angelos Evripiotis wrote:
> Hi!
>
> I noticed much earlier on this thread that we are proposing to add a
> '.bst' directory to every workspace, so that we may map back to the
> originating project.
>
> I mildly prefer that we choose '.bstworkspace' or something similarly
> more descriptive instead.
>
> This is partly because I can imagine we might have some other use for
> '.bst' later, with it being quite a general name. Admittedly I don't
> have an example.

By your logic that we might want some extension to this, we should
essentially prefer a `.bst` directory, and reduce pollution of the
workspace itself (i.e. we can add many files to the `.bst` directory
without polluting the workspace directory namespace).

However, I think that you have accidentally stumbled upon something
interesting, and begin to agree we should not use the `.bst/` directory
name for this.

My rationale is that the following workflow is possible and in fact
quite interesting and useful:

  * Open a workspace on a junction element

    This is now a workspace of a BuildStream project (I've already
    found it useful to do this a couple of times myself while
    using BuildStream).

  * Open a workspace from the workspaced junction element.

    I've not done this yet myself, but I can see how it can be an
    interesting workflow that people would expect to "just work".

    In this case, you now have a workspace that is a BuildStream
    project, and it has a local .bst state directory where *its*
    workspaces.yml are stored.

For this technical reason, I agree we should certainly use a different
name, and agree that `.bstworkspace` is a good name for a directory, as
the purpose of the directory itself is to store state that is relevant
to the workspace.

I think the file itself should have `project` in the name, rather than
`workspace`, because it's purpose is to lead us back to the project.

With that said; I hope that there is never any extension to this state
file beyond storing the path to the project, we already have the
project side `.bst/workspaces.yml` file where we store individual
workspace state, we should continue to store related state there.

If we propose to not have a directory and only have a file, I would
prefer the name `.bstproject.yml`.

Cheers,
    -Tristan