This is a bit of a hefty PR, since I was using these changes to refactor the Buildkit image building process, which is included in this PR.

The broad theme of these changes is to whittle away at scenarios where you have to fall back on Bash or other external tools, and to embrace compatibility with the goal of letting you use Bass for the end-to-end lifecycle of image building and publishing.

Add (write) for writing to disk

The first thing I noticed was I had an explosion of scripts involved in bumping Buildkit and building its image. I had Bass scripts that did "pure" things like emit a thunk or thunk path to stdout, and then Bash scripts that piped the exported to the filesystem.

The thought behind this was to keep Bass "sandboxed" so it's not able to write to the host filesystem. But dealing with these wrapper scripts is just way too painful.

Now it's possible to write to the host, with two safeguards:

• You can only write to a path within a HostDir. You can't write to arbitrary paths.
• Bass internally writes to a bass.Filesystem abstraction. By default it uses the host filesystem, but something integrating with Bass (e.g. Bass Loop) can override it with a read-only or empty filesystem.
  • Technically Loop doesn't need to do this since it never exposes a HostPath in the first place, but it's still nice to support sandboxing.

In addition, writes are atomic. This makes it easy to pass a file to a command for processing and then (write) the result to the same file. Without atomic writes it would truncate the input before/while it's being processed, which is a common footgun in Bash.

Add (publish) for pushing a thunk to a container registry

Another thing I relied on Bash wrappers for was pushing images to a container registry. Now you can just (publish) directly from Bass. No need to (export) to disk and then pass to skopeo or docker for pushing. Much faster!

Add (docker-build) for building from Dockerfiles

You can now build images using good old Dockerfiles. I needed this because I wanted to be able to use a fork of Buildkit by building from the Dockerfile in its repo.

Currently this is its own special type of image, slotting in alongside OCI archive images, image refs, and thunks. So you don't 'build' a Dockerfile into a Thunk, you can just use it as an image.

This will allow for far greater compatibility with the external world. Bass doesn't replace Dockerfiles; it's far too opinionated. Dockerfiles will probably exist until the end of time if not just as a language-neutral format for building images.