Buildkit frontend

[vito]

Implements a Bass Buildkit frontend, so you can write a Dockerfile like this:

# syntax = basslang/frontend:dev

(from (linux/alpine)
  ($ echo "Hello, world!"))

The first line tells Buildkit to use the basslang/frontend:dev container to build the Dockerfile. This means you can use Bass anywhere you can use a Dockerfile. No installation or setup necessary.

The Bass frontend evaluates the script, which must return a thunk, which the frontend then builds using the Buildkit runtime.

• *dir* will be the path containing the script, if it is different from the context dir. Use it for loading Bass code.
• *context* will be the context dir. Use it as your build input. (I might consolidate this into *dir*.)

Almost everything works, with a few exceptions which don't seem like dealbreakers given the use case:

• Services don't work when running in vanilla Docker, because Docker's engine doesn't have container-to-container DNS.
  • Services do work when running in Bass via (docker-build) (Add (write), (publish), and (docker-build) #270) using the Buildkit runtime.
  • Services should work when using the Dagger runtime too, but I haven't tried it yet.
• (publish) will not work because Buildkit doesn't support exporting in the gateway interface.
  • Add export to Gateway API moby/buildkit#1914
  • But it would be kind of strange to (publish) in a Dockerfile anyway. I'm not sure if this should be fixed really.
• (write) will not work because the filesystem is not writable. This is doesn't really fit the use case either. Actually it might just do something really weird. I haven't tried.

For a more complicated example see Bass's own Dockerfile which reuses Bass's existing CI code to create an image for running bass:

# syntax = basslang/frontend:dev

(use (*dir*/bass/bass.bass))

(def dist
  (bass:dist *context* "dev" "linux" "amd64"))

(-> (from (linux/alpine)
      ($ cp dist/bass /usr/local/bin/bass))
    (with-entrypoint ["bass"]))

Unfortunately this can't be built with docker build because it uses a service (Nixery) for building images. I'm hoping to replace that with a regular nix build instead -- using this frontend!

Until then, here's a Bass script that runs it:

(run (from (docker-build *dir* {:os "linux"})
       ($ --version))) ; note that entrypoint is respected. not sure about this tbh. looks weird.

I'll be waiting for some nerd to waltz in and see a Dockerfile in the repo and think "Ha! So much for defeating Dockerfiles!" only to open it and see Bass code.

TODO:

• Try using it from the Dagger runtime. In this case I guess it would be a funky hybrid where Bass's Buildkit runtime is used within the Dagger runtime?!
• Get rid of *context*? should *dir* just be script dir and the context dir? I'm not sure when they would ever be different. Dagger and the Docker CLI don't seem to let you do this.
• Put build args somewhere. Maybe *env*?
• What other things need to be exposed?
• Point the filesystem to a DiscardFilesystem so (write) doesn't do strange things (*dir* is technically a host path, but its context dir refers to a named input, not a directory).
• Support returning a thunk path from the script, pointing to an OCI image tarball. This way Bass can be used as an entrypoint to other build tools like nix build.