|
| 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) |