Docker image with Nix inside

[garbas]

This work was borrowed from NixOS/docker#31

[Ericson2314]

You shouldn't need a native band cross package set, instead take a single host Nixpkgs, and use buildPaclages to get a build time package set out of it.

https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/linux/make-bootstrap-tools.nix and https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/linux/make-bootstrap-tools-cross.nix (a thin wrapper) show what i mean.

[edolstra]

Maybe it's better to initialize the profile by running nix-env -i ${defaultPkgs} or something like that. That way we don't have to generate an (old-style) manifest.nix here.

[garbas]

I'm not 100% but if I remember correctly I wasn't able to generate profile with nix-env. Maybe @adisbladis knows more about since this is version of creating profiles.

[edolstra]

We should document somewhere (e.g. in the installation section of the manual) how to get our docker image and what it provides.

[garbas]

We should document somewhere (e.g. in the installation section of the manual) how to get our docker image and what it provides.

I'm not sure this would fall under the installation section, since you are not really installing Nix, but you would be just using it like any other docker image. I wonder if the website would be the best place to document it.

[roberth]

I would prefer for this image to be defined in the nixpkgs repo, because this repo is bottlenecked by reviews and won't have the pace of development that nixpkgs has. Also, as a dockerTools maintainer, I'd like to include the official nix image in the dockerTools test suite.

cc @utdemir

[garbas]

@roberth I don't object to the idea that the helper functions for Nix image to be defined in nixpkgs. Not the docker image itself but only the helper function that also others can use to create their own custom Docker images with Nix inside.

But the official docker image should be defined in this repository alongside the Nix code.

[roberth]

@garbas So if I understand correctly, you're suggesting to keep the final image definition in this repo, like image = pkgs.buildNixImage { nix = self.nix; } (omitting system tomfoolery for brevity) but have almost all of the implementation of the image in Nixpkgs?

That seems like an improvement, but it does complicate the release process, compared to a release process that is steered by Nixpkgs. I suppose "gatekeeping" could be a good thing for trust. Is that what you had in mind?

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/tweag-nix-dev-update-21/16032/1

[edolstra]

I would prefer for this image to be defined in the nixpkgs repo

It seems very strange to have the release process for Nix in another repo.

That seems like an improvement, but it does complicate the release process, compared to a release process that is steered by Nixpkgs.

I don't understand this. Why should the Nix release process be steered by Nixpkgs?

[roberth]

I would prefer for this image to be defined in the nixpkgs repo

It seems very strange to have the release process for Nix in another repo.

The docker image isn't the same as the Nix package. This repo is hard for the community to make changes, unlike Nixpkgs. If you don't consider Nixpkgs to be part of the Nix release process, I'd find that rather concerning.

That seems like an improvement, but it does complicate the release process, compared to a release process that is steered by Nixpkgs.

I don't understand this. Why should the Nix release process be steered by Nixpkgs?

It reduces the cyclic dependency between Nix and Nixpkgs. Again, I'm not saying Nix should be released by Nixpkgs; just the docker image.

I wouldn't be concerned if this project had more than one maintainer who merges PRs.

[edolstra]

If you don't consider Nixpkgs to be part of the Nix release process, I'd find that rather concerning.

Ehm...? Nixpkgs is a dependency of the Nix release process, but that doesn't mean the Nix release process should be moved into the Nixpkgs repo. Might as well move it into the gcc repo...

What exactly is the use case for putting this in the Nixpkgs repo?

It reduces the cyclic dependency between Nix and Nixpkgs.

What cyclic dependency?

[roberth]

What cyclic dependency?

Nixpkgs depending on Nix and Nix depending on dockerTools.

Might as well move it into the gcc repo...

I figured you might take this to an extreme. That's not the point. Less cyclic is generally better. I'm not saying it is completely avoidable. That would make no sense, as you know.

I wouldn't be concerned if this project had more than one maintainer who merges PRs.

I'm just trying to help with the maintenance load. I feel this discussion has reached the tipping point, so I'll shut up now and hope that you'll have time to review fixes.

[domenkozar]

@garbas do you plan to setup jobs to push this docker image to docker hub?

[Ericson2314]

What about the comments I left in #5453 (comment) ? I suppose I will make a PR against this, sigh.

[garbas]

@domenkozar Yes, this was the first step.
@Ericson2314 As conversation moved later on docker.nix will be anyway extracted into nixpkgs as a function (eg. buildNixImage) which we will than use here. I think having everything in one file will make that easier migrate.

[Ericson2314]

@garbas I wasn't asking for more files? I will open a PR in a second with the changes I had in mind. I think it a fine change whether the stuff is living here temporarily or permanently, though yes my original motivation was people will look to this repo to see how things ought to be done, and I don't want them to come away with an unusual style.

[Ericson2314]

PR's up #5573

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/tweag-nix-dev-update-24/17230/1