Hi all,
We're sending this email out with the aim to consolidate the outcomes of
the discussions around 'Proposal: Workspace related DX features & design'[1]
Part of the outcome of this summary will be the consolidation and
potential creation of new gitlab issues as explained in the original
email. Each issue will take into account the details in any related
original issues along with the discussion generated from the initial
Workspace DX proposal email. This will also accommodate for further
discussion on the specific tasks.
Points to cover:
1. run bst commands in workspace directories, including defaulting
command to said workspace element.
2. Make workspace creation easier.
- Default location
- Automatic names.
- Making multiple workspaces
- Relative paths
- Use of cached builds/buildtrees
- Moving workspaces
3. Debugging in bst shell, workspace considerations
1. ============
- Using .bstproject.yaml as the workspace fragment, only
contains the path to its parent project (or other projects that have
been forcefully associated to it), non-extensible.
- Support for multiple projects pulling a workspace is not allowed by
default but it can be forced with known side-effects. Default behavior
is to say a workspace already exists at a given location with a given
name, along with what project it belongs to. If forced to be a workspace
for multiple projects then the original parent project takes precedence
by being the first entry in the .bstproject.yml fragment (i.e. is the
default resolution unless overridden with --directory). bst commands
again need to be forced & warn the user that it may affect other
projects consuming the shared workspace.
+1.
2. ============
- Default location to be set at user level, with the standard levels of
provenance. Both the default directory & --directory at cli are
referring to the 'root' directory in which directories for workspaces
will be created, with each element's workspace named after the
respective elementname as subdirs.
- Multiple workspaces:
~~~~~~~~~~~~~~~~~~~~
bst [project options] workspace open [open options] element1.bst
[workspacename] \
--open [open options] element2.bst [workspace name] \
--open [open options] element2.bst [workspace name] \
...
- [project options] = --directory pathto/project \
...
- [open options] = --directory pathto/workspace \
--no-checkout \
-f --force \
--track \
...
- [workspace name] = optional value to override the default behaviour
of naming workspaces as elementname
I don't think this is the consensus we reached. My impression was that we ended with:
bst [project options] workspace open [--directory DIRECTORY] [open options] ELEMENT
bst [project options] workspace open [open options] ELEMENT [ELEMENT ...]
[...]
3. ============
- The topic of debugging in the bst shell (including the mounting of all
relelevant workspaces into it) was briefly raised in the initial
proposal to try and identify any knock-on effects this would have on the
workspace cli. However, the consensus gathered was that this would not
be the case. Therefore we will not consider this case anymore as part of
this proposal and as such should be continued in a separate proposal.
+1.
Cheers,
Sander
Regards,
Tom & Will
[1]
https://mail.gnome.org/archives/buildstream-list/2018-August/msg00078.html
--
https://www.codethink.co.uk/privacy.html
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
