Re: [BuildStream] Bst workspace - UX feedback and change suggestions

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

On Tue, 2018-08-07 at 09:11 +0100, Daniel Silverstone via BuildStream-list wrote:
> On Tue, Aug 07, 2018 at 14:47:53 +0900, Tristan Van Berkom via BuildStream-list wrote:

[...]
> > I don't think the answer here is to strive for symmetry with `bst init`
> > (although bst init most certainly creates the project directory, when
> > one is specified, like `bst -C <project_dir> init ...`), I think that
> > `bst init` is sufficiently special.
>
> I will say that, as someone new to `bst` a couple of weeks ago, the lack of
> consistency between `bst init foo` (errors) and `git init foo` (works, makes
> foo) and `bzr init foo` (works, makes foo) tripped me up more than once.  My
> fingers (as a long-time 3-character tool user) expect `XXX init foo` to "just
> work" :-)  (Though this is not the topic for Phillip's testing, so I'll shush
> for now).

I think you misread this, or are replying only to my parenthesis.

I think we are mostly in agreement that it would be nice for `bst init`
to behave more symmetrically with *other tools*. My comment is that we
should not necessarily be striving for symmetry with `bst init` when
designing other bst commands, like `bst workspace open`, because `bst
init` is quite special and different from other bst commands.

Regarding `bst init` symmetry with other CLI tools; While I'm not a fan
of adding redundant API surface, it would be possible to add an
optional directory argument to it without breaking API.

Since we landed #368 (allows running BuildStream from a project
subdirectory), it would be possible to safely change the meaning of
the `-C/--directory` option to:

   "Resolve all input paths to absolute paths first, and behave as
    if we were launched from the specified directory"

> > I.e., if we're going to populate the workspace directory with the
> > content of what would be staged for that element; I think it makes
> > sense to expect we will create the directory.
>
> Perhaps if we're told the name of a dir which exists and is empty, we could
> reuse it?

On it's own, this sounds fairly sensible, but we have other things to
consider too, e.g. 

    https://gitlab.com/BuildStream/buildstream/issues/229

I think that it would be more desirable to make the directory
completely optional, and the behavior dependent on user preferences.

We will need to take all of the enhancement requests into account if
we're going to do any overhaul of the workspace commands.

For the rest of this message, refer to my fork of this thread.

Cheers,
    -Tristan