[BuildStream] Buildstream shell et al

[Sander Striker <s striker striker nl>]

Hi,

Are we expecting the user to have a full environment, including their favorite debugger included in the shell environment?  Given that that means first making all these tools available through .bsts somehow, realistically the answer to that is no.  The question then becomes, how do we bring together build isolation and user convenience and control?

Now, I don't think we can solve this for everything.  If you're building systems, and bootstrapping from scratch on exotic or uncommon environments, the only path you have may be to have all the tools be part of the .bst definitions.

However, when on more mainstream platforms, there is potentially an easier path.

The following is meant as food-for-thought, not a fully baked proposal.  I'm going to highlight one use case only:  I am a developer and my build has produced a binary that fails in a seemingly awkward way.  Now, I am proficient with SwankyDebug, but that is not available in bst shell.  Now, I also know from experience that once I am using debugger, I am going to make code changes and need to rebuild.  How do I get access to both my debugger and my build environment?

Consider the following just brainstorming...  

If we can actually generate a Docker container which contains the entire staged build environment including mounting of workspaces, then the user can take it on themselves to extend the docker container to have whatever tools desired.

Note that there currently is no facility to create your entire build environment outside of a bst shell, other than by hand walking the dependencies and doing bst checkout.  Workspace builds, that is, running bst build on a workspace, need to be good enough to not have anyone want to do this in the common case.

A naive implementation could be as simple as a special Sandbox* that creates a Dockerfile as such:

FROM scratch

# Staging

COPY path/to/hashed/content/in/local/cas /actual/path

...

# Workspaces

VOLUME /path/to/mount/for/workspace

...

And generate the proper commandline invocation for it, so the relevant open workspaces would be properly mapped to the volume locations.

Now the user can choose to exit the docker container.  And write a Dockerfile that extends the one above that pulls in SwankyDebug.  Launching that container gives me everything I need.

One _could_ argue that doing a Sandbox implementation that uses OCI containers for everything instead of bwrap, would give us local builds on all platforms where Docker is available.  And would allow the user to leverage familiar tools to achieve their needs.

Cheers,

Sander

--

Cheers,

Sander