What if NixOS was just a normal derivation output?

Development
1

Thinking about design decisions that were made in the past. The nixpkgs repo contains both the packages and the nixos module system. What if we removed the distinction between both?

Simplified Hydra and Channels

  • Map 1:1 between github repos and Hydra projects
  • Channel names would map 1:1 with jobsets under the nixpkgs project.

So in the end we would have:

  • channel:nixpkgs-unstable
  • channel:nixpkgs-18.03 and other releases

At the moment I never really know where to look in Hydra. It prevents me from finding why a package is broken in my channel and fix it.

Simpilfied naming

One less thing to explain. There is nix, and nixpkgs (and nixops).

NixOS is just another derivation output

Now that NixOS is part of nixpkgs, we should also be able to do:

{ pkgs ? import <nixpkgs> {} }:
pkgs.mkNixOS {
  # No config available here, they would only be available in imports
  imports = [ ./hardware-configuration.nix ];
  # You can do all the normal config as usual
  environment.systemPackages = with pkgs; [ curl ];
}

It’s already possible to do something similar today but it’s not very accessible and requires importing lib files.

Merged documentation

We have pretty good documentation but it’s hidden in different places. Merging the NixOS and nixpkgs documentation would make things much easier to follow.

What do you think?

2

I’m not sure how merging the documentation for the nixos modules will help, unless that documentation now becomes relevant outside of mkNixOS. That is, I don’t think what’s proposed would make NixOS configuration work on non-NixOS.

Though, I am for a merging of the manuals, considering that the merged manual is split-back into sections in different pages (by default). That is, one documentation build builds both nixpkgs and nixos (possibly even nix); those manuals already are quite big.

I’m thinking something like nixpkgs manual’s chapters 9, 10 and 11, three chapters about domain specific knowledge (9. Support for specific programming languages and frameworks, 10. Platform Notes, 11. Package Notes) into its own “B.” section, this could help make both part more approachable.

If nix, nixpkgs and nixos's manuals are brought together, some parts could be put together, like package management, writing nix expressions, the function references. Though it would be primordial that those sections make it clear how they are relevant to either of the two or three projects.

This all said, I am not sure how it could be managed through docbook, if at all. The nix manual would still need to be able to be built without merging it with nixpkgs, and each manuals should make sense in isolation. Parts that would usually be merged could become See also sub-sections?

I’m not sure if I managed to make my ideas understandable though, ask if it isn’t.

3

This also raises the question about keeping Nix and nixpkgs/lib separate. In theory it’s nice to have a nice distinction between the minimal “core” and the tools implemented in terms of it, but as a user it gets confusing not having a “one stop shop” to look through. lib imports most of the builtins wholesale and adds some tools of its own, but some seem to be forgotten (builtins.readDir and builtins.match come to mind), and some are changed slightly vs the builtins version (for example, see lib.splitString vs builtins.split).

Search! Ideally there’d be some global search between all pages, but until then Ctrl+F is the best we have.

1 Like