add services via thunk addrs

[vito]

• thunks now configure a list of named ports that they listen on
• (addr thunk name format) returns a thunk addr(ess), a new value type

A thunk addr is sort of like a thunk path except it refers to a TCP address of a service run by a thunk rather than a file created by a thunk. It embeds a format string for the address which will be rendered at runtime.

Just like thunk paths, thunk addrs are just data values. The service thunk only runs when it's needed by another thunk.

When a thunk addr is passed to another thunk the runtime will run the embedded service thunk, poll until all ports are live, and then render the format string with an appropriate host and a port reachable by the consumer thunk. The format string uses os.Expand syntax, which is just $foo and ${foo}.

Here's a simple client + server:

(def server
  (from (linux/nixery.dev/simple-http-server)
    (-> ($ simple-http-server)
        (with-port :http 8000))))

(-> ($ curl (addr server :http "http://$host:$port"))
    (with-image (linux/nixery.dev/curl))
    run)

Or, pointlessly:

(run (from (linux/nixery.dev/curl)
       ($ curl (addr (from (linux/nixery.dev/simple-http-server)
                       (with-port ($ simple-http-server) :http 8000))
                     :http
                     "http://$host:$port"))))

See also demos/addrs.bass.

When a thunk completes, Bass "disconnects" from the service thunk, stopping it if it's the last thunk using it. Thanks to Buildkit semantics there will be only ever be one instance of a service thunk running, and its progress will be multiplexed to all clients. It will only be interrupted when all concurrent clients disconnect. This means multiple thunks using the same service will all share the same service as long as at least one of them is running.

With this design you can use services like values without worrying about managing complicated lifecycle across many runs. The service will appear when it's needed and disappear when it's no longer needed.

Currently buildkit does not support container networking (just "host" or "none") so $host will always be localhost or 127.0.0.1, but support for that may arrive someday: moby/buildkit#28

show me!

bonus material

nixery

A thunk addr may also be used as a thunk's image repository to run images from a local registry service thunk. See nix.bass for using Nixery.

add (wait), interrupt on exit

By default, scripts now interrupt any background thunks before waiting on exit. This way you can start services in the background if you want to and they'll be automatically cleaned up.

To wait for background thunks instead of interrupting them, use the new (wait) function.

hashes changed from base64 to base32

Thunk hashes have been changed (again - #203) to base32 encoding instead of base64. This is a speculative change so they can be re-used for hostnames in the future. Base32 is still short enough, but it's a bit screamy. Leaving it as-is for now.

refactor image archive out of image ref

Support for OCI image archives was shimmed into the existing image ref type, which felt a little misfit since not all fields were relevant between them. It has been refactored out into a separate ImageArchive.