I would love to see more development in this space. I'm aware of tools like bazel, nix, and jib (I feel like I've seen an equivalent to jib for Go) that can build Docker images "outside" Docker/BuildKit. I believe the .NET SDK can do something similar for .NET applications. And then there's tools like buildpacks, nixpacks, devbox, etc that still use Docker to produce the image, but don't require thinking in Dockerfiles.
I have some ideas I want to explore with Depot, but it really it feels like it should be possible to make cross-compiling and dependency encapsulation easy to use, so "building a container image" is reduced to creating a tarball in the correct OCI format, and you don't have to interact with Dockerfiles as much if you'd prefer not.
I’ve used jib and bazel and that’s exactly what they do, both are language agnostic and push files around. Jib has a java bent but not a required part of it.
I can totally see people using Depot bc it’s way easier and more obvious, works in the obvious way, and that is how things work today. It doesn’t challenge you to think, why the hell do I need a super privileged process with magic Dockerfile incantations just to take a tar of files and add another file to it? With some metadata? Docker has created some weird defaults.
I have some ideas I want to explore with Depot, but it really it feels like it should be possible to make cross-compiling and dependency encapsulation easy to use, so "building a container image" is reduced to creating a tarball in the correct OCI format, and you don't have to interact with Dockerfiles as much if you'd prefer not.