[HN Gopher] Nixpacks takes a source directory and produces an OC...
       ___________________________________________________________________
        
       Nixpacks takes a source directory and produces an OCI compliant
       image
        
       Author : ghuntley
       Score  : 67 points
       Date   : 2022-08-17 20:43 UTC (2 hours ago)
        
 (HTM) web link (nixpacks.com)
 (TXT) w3m dump (nixpacks.com)
        
       | ris wrote:
       | 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.
        
         | justjake wrote:
         | Sorry which distribution exactly? We utilize the python's
         | nixpkgs versioned packages
         | 
         | See:
         | https://github.com/railwayapp/nixpacks/blob/f88718efe1156671...
        
       | xelxebar wrote:
       | 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?
       | 
       | 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.
       | 
       | [0]:https://github.com/oriansj/stage0
        
       | mrkurt wrote:
       | We added experimental support to Nixpacks for Fly.io (it's baked
       | into our CLI). I'm very excited about it, buildpacks have been a
       | nightmare.
        
       | jbboehr wrote:
       | 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.
       | 
       | [0]:
       | https://github.com/railwayapp/nixpacks/blob/60ab563fdc9bf4fb...
        
       | 0xferruccio wrote:
       | Loved this! Tried this on a rails app for a side project and it
       | worked out of the box
        
       | chriswarbo wrote:
       | Looks like this requires Docker to be available?
       | 
       | Personally I've been making OCI images using Nix, just by running
       | tar, sha256sum and jq:
       | 
       | - We can get a Nix derivation's dependencies using
       | `writeDependenciesToFile`
       | 
       | - 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.
       | 
       | - A "digest" is just a JSON file like `{size: 123, digest:
       | "abc"}`, e.g. generated using `stat` and `sha256sum`
       | 
       | - Those sha256sums can be referenced in a config.json, like
       | `{"rootfs": {"type": "layers", "diff_ids": [...]}}`; along with
       | the application-specific config (EntryPoint, WorkingDir, etc.)
       | 
       | - 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.
       | 
       | 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.
        
         | ris wrote:
         | Um.. `dockerTools`/`ociTools`?
         | 
         | https://nixos.org/manual/nixpkgs/stable/#chap-images
        
       | gavinray wrote:
       | Neato -- so basically Buildpacks[0] redone with Nix?
       | 
       | [0]: https://buildpacks.io/
        
         | justjake wrote:
         | It's in the same vein, but our goal is to create a standard for
         | fully reproducible builds
         | 
         | Nixpacks can also spit out a plan
         | (https://nixpacks.com/docs/how-it-works#plan) which, when run
         | again, will assure that the build artifacts the exact same
         | every time it's run against that plan.
         | 
         | The result is that any code that's built with nixpacks has all
         | it's dependencies snapshotted so it won't break over time.
         | 
         | For us, that means anytime someone comes to our platform
         | (http://railway.app/) and deploys an Template, it won't be
         | broken
        
       | 0x69420 wrote:
       | 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
       | 
       | 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
       | 
       | for anyone interested, prior art on the nix container front:
       | https://nixery.dev
        
         | justjake wrote:
         | The similarity is definitely on purpose. It pulls ideals from
         | both nixpkgs as well as the cloud native buildpacks.
         | 
         | Our goal is to make reproducibility more approachable/less
         | cumbersome, and for people to be able to define additional
         | nix/apt/etc packages added to the container .
         | 
         | You can add package you'd like via the environment variables
         | NIXPACKS_PKGS (or NIXPACKS_APT_PKGS for apt)
        
       | jonringer117 wrote:
       | Nice, really interesting usage of nixpkgs :). Almost a command
       | line friendly version of docker build.
       | 
       | I like it.
        
         | justjake wrote:
         | That's the ideal! 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
         | 
         | BuildKit makes this possible and we've got lots of stuff
         | planned. Would love to hear anything you can think of that
         | would make this more friendly!
        
       | justjake wrote:
       | Oh neat. We've been meaning to post this on HN!
       | 
       | We're the people behind nixpacks; happy to answer any questions
       | just holler
        
         | ghuntley wrote:
         | It's a small world. Shoutout to Domen (https://www.cachix.org/)
         | who introduced me to nixpacks.
        
       ___________________________________________________________________
       (page generated 2022-08-17 23:00 UTC)