Hi Sander,
[...]
> I don't know how common this use case of having multiple projects refer
> to the same workspace is going to be, but it doesn't sound too expensive
> to support it regardless.
Yes to be frank it's a situation that I'd like to avoid, however I can
see some benefits when working say on a crucial dependency that is
in-flight which is being actively consumed by many projects and as such
debugging from a single source point may be more efficient (of course,
this relies on the base source ref being the same). As stated it would
be something that a user would have to force, I think giving a warning
is about as expensive as it should get.
I can see that use case. And thanks for confirming that it would be trivial to support.
[...]
>
> When opening a single element then you can:
>
> bst workspace open --directory /path/to/workspaces --multi
> elementA.bst elementB.bst
>
>
> Why do we need the --multi argument? That doesn't seem intuitive. If
> it is to get around the fact that otherwise elementB.bst would be
> interpreted as the workspacename, then I don't think we should do that.
> Otherwise you end up with an open workspace carrying the name of the
> second element you wanted a workspace open for.
Yes it is to mitigate the situation you've mentioned. Will has some
thoughts about handling this with click in alternative ways, however as
it stands the most sane thing seemed to be the use of an additional flag.
I'm opposed to the --multi flag. I don't think it's intuitive.
I am definitely concerned about this invocation in the current proposal resulting in:
$ bst workspace open elementA.bst elementB.bst
... opens up a workspace for elementA.bst in a directory called /path/to/workspaces/elementB.bst...
I think it makes more sense to in this case make a backward incompatible change to the CLI, for the benefit of a better user experience.
[...]
> The directory option specifies the directory, in which the folder
> containing/(the root of) the workspace will be created. The folder
> containing/(the root of) the workspace is either the "workspacename"
> from the
> command line or if not given then it is the element name without the
> trailing
> ".bst".
>
> eg. `bst workspace open --directory /path/to/workspaces elementA.bst`
>
> would create:
> path/to/workspaces/elementA/
> as the root or the workspace
>
> and `bst workspace open --directory /path/to/workspaces element.bst
> workspacename`
>
> would create
> path/to/workspaces/workspacename/
[...]
> What is the sensible default location used when no workspace location is
> defined? 'workspaces' as a subdirectory of the project directory? Or
> will not having it set result in a helpful failure message?
My preference would for be the command to behave as is to not break any
compatibility with any existing automated workspaces. As such I'd
propose to keep the existing helpful failure message, all be it reworded
to include the availability of defaults. Having workspaces as
sub-directories of a project is also a workflow in which Tristan has
been an advocate of not recommending (see issue #191), so making this
default behavior would be somewhat challenging that.
I'm ok with challenging Tristan on this one as I am still not convinced that it's that bad (Hi Tristan ;)). However I am not necessarily opposed to have the helpful failure message with clear instructions how to configure. What would result in the best user experience?
[...]
> What is the recovery mode for a moved workspace that can't find its
> project? Can it be re-registered?
Will mentioned that a user could 'fudge' the path given in a workspace
fragment which would allow for manual intervention in the case of
re-registering. Ultimately that's a bit messy so going forward with a
utility (a new flag for bst workspace?) for the re-association of
workspaces to projects is probably the right thing to do.
+1. I don't really like the idea that we end up with an FAQ that tells you to edit the 'fragment'.
How 'smart'
this command would be, especially when trying to generate a list of
potential parent projects, is something that would need to be more
fleshed out if desired.
I think we'll be ok if we ask for confirmation to replace all associations with just the association to this single project.
[...]
> I feel that half of the proposal is non-contentious and the other half
> is around Debug. From the above I am not clear there are going to be
> any conflicting workspace CLI changes needed, it seems not. Can we
> separate out Debug on that basis?
I agree here that the majority of cli changes needed (or as we currently
see as needed) here are for bst shell. However there is definitely
overlaps & the point of using cached build trees (& especially if they
are to become by default what is currently checked out into a workspace)
are places that we feel benefit from being in the overarching design
proposal. If deemed necessary I'd take no issue with the core design &
implementation of extending debugging with bst shell to be separated out.
That would be my preference if there are no objections.
Cheers,
Tom
Cheers,
Sander
