Nixpacks takes a source directory and produces an OCI compliant image

Re:Nixpacks takes a source directory and produces an OCI com... by ris on Thursday August 18, 2022 @03:29PM (#32513845)

Indeed, it's a compromise. Something I can't figure out though is if you make any attempt to remove unnecessary nix packages for the final image, i.e. in cases where a (language-)package has a native module built from source, can you generate a final image without gcc present?

There are a couple of sneaky ways this could possibly be done, but wondered if you explored any of them.

[ Parent | on HN ]

Re:Nixpacks takes a source directory and produces an OCI com... by justjake on Friday August 19, 2022 @01:57AM (#32517895)

I don’t think we are ATM but would absolutely love a PR/suggestion for this!

Would love to drop image sizes

[ Parent | on HN ]

Re:Nixpacks takes a source directory and produces an OCI com... by ris on Friday August 19, 2022 @07:11PM (#32527200)

Having just written up some thoughts on how you could do it I realize they wouldn't work, because I imagine you're presenting a "standard"/FHS-esque view of the filesystem to the non-nix packages, i.e. they expect a `/usr/lib/libssl.so` to exist. Whereas Nix's ability to strip away runtime-unnecessary packages comes from packages only ever using explicit absolute references to each other.

I guess a "third way" might involve using e.g. pypi2nix, bundix, node2nix and the like.

[ Parent | on HN ]