Nix packaging, the heretic way

18 Likes

This is really great!

When trying to introduce Nix into corporate environments, being able to easily get your feet wet with these types of non-sandboxed builds can be a nice way to start using Nix. You can benefit from some of the advantages of Nix, while not having to completely jump into the deep end with the semi-hacky *2nix solutions.

Once Nix has been introduced (even using non-sandboxed builds), it is a lot easier to go and clean things up. I’ve found it is often easier to sell to a company “a little bit of work every day over a few months”, than “3 weeks of work upfront”. Especially with things like build infrastructure!

4 Likes

Thanks, you got my point perfectly.

The alternative I have seen in the wild, when projects are hitting that purity wall, is to fall back onto the nix-shell. The CI is then something like nix-shell --run "./ci.sh". But that’s not composable anymore; the build product is not easily available to make it part of some other derivation. And is even less pure because all the user environment leaks into the build.

3 Likes

https://github.com/numtide/nix-filter is also a nice take-away from this, I’ve been looking for something that helps, the built-in filters are painful :smiley:

4 Likes

I’m getting Cloudflare “Error 1016” for the link, wondering if it’s just me

The blog post works for me.

I like it a lot! What would be arguments against introducing a buildNodeApplication function based on __noChroot? It seems that this could be much more composible (and easier?) compared to docker.

@bobvanderlinden

They can’t be cached or shared, so it’s not ideal for a permanent solution. The article covers this in more detail, but it’s usefulness is more limited to closed projects.

Super useful techniques in here.

1 Like

I’m not sure if you’re suggesting a function like buildNodeApplication should go into Nixpkgs, but if you are, there is at least some prior art.

There is a stack builder for Haskell in Nixpkgs that uses __noChroot and accesses the internet:

Although I’ve never seen this used in the wild.

edit: I guess this doesn’t need to be said, but things like this stack builder for Haskell or a hypothetical buildNodeApplication function can’t be used within Nixpkgs, but they could still be defined in Nixpkgs and used by people working on projects outside of Nixpkgs.

This is similar to how IFD can’t be used in Nixpkgs, but there are still functions defined in Nixpkgs that use IFD, and are meant to be used in projects outside of Nixpkgs.

1 Like

I’m targeting private repos only.

Using __noChroot = true means that the project is now more susceptible to supply-chain attacks. Nix doesn’t provide the guarantee that the output is the same anymore. Typically the build would use npm, cargo, … who do their own checksum checks, but if the build does something like curl some random website, now the website can change the content of that file for subsequent builds.

Just saying that this needs to be done responsibly. And we can’t really open that for nixpkgs without compromising the project’s fundamental guarantees.

Technically we could extend the builder APIs so vendorSha256 can take an “impure” argument, and then use that only outside of nixpkgs. But I think it would be confusing for packagers. Now they have to know which arguments are meant for nixpkgs, or to use outside.

8 Likes
Hosted by Flying Circus.