On Wed, 2017-07-26 at 13:24 +0000, Sander Striker wrote:
> Hi,
>
> I was looking at the workspaces implementation and was wondering if
> we should expose the workspace operations to/in the source
> providers. The default implementation could follow what we do today.
>
> This will allow the source providers to use more efficient operations
> for opening the workspace. e.g.
> https://gitlab.com/BuildStream/buildstream/blob/master/buildstream/_p
> ipeline.py#L55 will end up calling https://gitlab.com/BuildStream/bu
> ildstream/blob/master/buildstream/plugins/sources/git.py#L146 for
> creating a workspace for a git backed project. However, the --no-
> hardlinks option makes this potentially a lot more inefficient than
> it needs to be.
>
> Exposing it also allows a source plugin to provide workflow specific
> setup. e.g. setting up remotes in a certain way.
Hi Sander,
Indeed I had originally thought of adding support from the Source
plugins for this feature, mainly because I wanted the UX for the
remotes to be linked to their real origins instead of just cloned from
a buildstream cache.
The rationale for leaving that out was mostly because workspaces were a
fairly complicated feature, and having support from the Source
implementations was quite orthogonal and as such should not block the
feature from initially landing (we just want to look at this as an
enhancement to the base feature).
Makes perfect sense.
Right now it seems to me that it's not an immensely pressing feature,
but I've added an issue for it here:
https://gitlab.com/BuildStream/buildstream/issues/53
Thanks!
Also, it was a bit annoying to think of implementing this for every
supported Source implementation, so I think that we should probably
allow Source plugins to only optionally implement this participation
and just fallback to the current behavior in the case that there is no
added support.
+1. No need tor require every source plugin to implement this.
Cheers,
-Tristan
Cheers,
Sander
