Looks like this requires Docker to be available?<p>Personally I've been making OCI images using Nix, just by running tar, sha256sum and jq:<p>- We can get a Nix derivation's dependencies using `writeDependenciesToFile`<p>- We can put these dependencies (alongside anything else we like) into an OCI "layer" using GNU tar: the `--hard-dereference` and `--mode=755` options work well, and we can include directories using `-C /foo --filesFrom=foo.txt` where foo.txt comes from `cd /foo && find . -maxdepth 1`, with the leading `./` removed.<p>- A "digest" is just a JSON file like `{size: 123, digest: "abc"}`, e.g. generated using `stat` and `sha256sum`<p>- Those sha256sums can be referenced in a config.json, like `{"rootfs": {"type": "layers", "diff_ids": [...]}}`; along with the application-specific config (EntryPoint, WorkingDir, etc.)<p>- Finally, a "manifest" is just another JSON file; with `{"mediaType": "application/vnd.oci.image.config.v1+json"}` for the config digest, and `{"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip"}` for each layer digest.<p>Unlike Docker, these commands can all be run directly (from the "host", although it's not really hosting anything, since we don't need any containers or VMs to run the above); their contents are completely declarative (since we're just zipping up pre-existing files, e.g. built/fetched by Nix; rather than mutating a filesystem in-place); we can do it on any OS (e.g. no need for a Linux VM on macOS); etc.
I've been using nix2container[1] for awhile now. It looks like this depends on Docker, have you guys considered removing that dependency? It shouldn't be necessary to create an OCI compliant image with Nix.<p>[1]: <a href="https://github.com/nlewo/nix2container" rel="nofollow">https://github.com/nlewo/nix2container</a>
Do builds use sandboxing? It appears not[0], is this in the roadmap? Based on my experiences with node2nix, composer2nix, carnix, etc, I don't blame you for not going that route. Not to knock on the developers of those tools - it's a difficult problem. I apologize if my interpretation is incorrect.<p>[0]: <a href="https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb5540388680a2f368e0436db2/src/providers/php.rs#L82" rel="nofollow">https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb...</a>
Somewhat tangential, but I'm curious how big the bootstrap seed for Nix is. That is, if you wanted to build the entire world, what's a minimum set of binaries you'd need?<p>Guix has put quite a bit of work into this, AFAIU, and it's getting close to being bootstrappable all the way from stage0 [0]. Curious if some group is also working on similar things for Nix.<p>[0]:<a href="https://github.com/oriansj/stage0" rel="nofollow">https://github.com/oriansj/stage0</a>
This is really cool, and reminds me of some parts of Domen Kozar's recent talk titled 'Nix is going mainstream'¹. The crucial work of putting together this kind of really simple frontend seems like what he's talking about when he says we need 'our Docker', like how Docker built upon old tech (chroots, jails, LXC) to make it radically more usable.<p>--<p>1: <a href="https://youtu.be/WuWZqSSoLxY" rel="nofollow">https://youtu.be/WuWZqSSoLxY</a>
name is eerily similar to `nixpkgs`, i.e. the monorepo that defines all packages and one of the underlying technologies here. i get the play on buildpacks, but still, as a nix user it makes me do a double take reading the name<p>this is neat though, and in political terms, the elevator pitch mentions nix itself as an implementation detail in passing. hopefully, if this catches on, it'll function as a non-threatening gateway drug to nix itself, when users inevitably go digging into the weeds<p>for anyone interested, prior art on the nix container front: <a href="https://nixery.dev" rel="nofollow">https://nixery.dev</a>
It's interesting/neat, but it doesn't make use of e.g. nixpkgs' beautifully maintained python package distribution, leaving you with all the same pitfalls of pip/pypi as any other buildpack. And I don't imagine the end result will be a "pure" artefact, and so I can't see how they'd be able to safely remove the build-time packages from the final image.
I don't like the docs / project description. Everything is made 'so simple' that important parts are now gone and everything is now pure magic, I guess.<p>> We want to make it more trivial to build OCI compliant images without all the knowledge required to understand how Dockerfiles/Container Filesystem/BuildLayers/etc work<p>As someone who understands how the above mentioned stuff works - I feel like I'm being forcefully excluded from the tool's target audience as I need explanations and the docs are written with such an idea in mind that it is something I shouldn't know.<p><a href="https://nixpacks.com/docs/how-it-works" rel="nofollow">https://nixpacks.com/docs/how-it-works</a><p>> Nixpacks works in two steps<p>> Plan<p>> Analyze the app source directory and generates a reproducible build plan. This plan can be saved (in JSON format) and re-used at a later date to build the image in the exact same way every time.<p>How about an example of how a simple plan for a few projects would look like?<p>Plus, the tool seems to assume too much:<p>> To create the plan, language providers are matched against the app source directory and suggest Nix packages<p>I don't need no Nix in my images, no thanks.
I've just published a feedback article on Nixpacks since I experimented it 2 months ago. <a href="https://www.qovery.com/blog/my-feedback-about-nixpacks-an-alternative-to-buildpacks" rel="nofollow">https://www.qovery.com/blog/my-feedback-about-nixpacks-an-al...</a><p>TLDR; it's promising