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) (#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.
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:
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?!
[x] 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.
[x] Put build args somewhere. Maybe *env*?
[ ] What other things need to be exposed?
[x] 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.
Implements a Bass Buildkit frontend, so you can write a Dockerfile like this:
The first line tells Buildkit to use the
basslang/frontend:devcontainer 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:
(docker-build)(#270) using the Buildkit runtime.(publish)will not work because Buildkit doesn't support exporting in the gateway interface.(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:Unfortunately this can't be built with
docker buildbecause it uses a service (Nixery) for building images. I'm hoping to replace that with a regularnix buildinstead -- using this frontend!Until then, here's a Bass script that runs it:
I'll be waiting for some nerd to waltz in and see a
Dockerfilein the repo and think "Ha! So much for defeating Dockerfiles!" only to open it and see Bass code.TODO:
*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.*env*?DiscardFilesystemso(write)doesn't do strange things (*dir*is technically a host path, but its context dir refers to a named input, not a directory).nix build.