Two ways to write a Home Manager flake: is legacyPackages needed?

Help
1

Here is a boiled down version of my Home Manager flake. The legacyPackages part always seemed strange to me, but I took it as “the way it is done”.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

    home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = { nixpkgs, home-manager, ... }@inputs: {
    homeConfigurations = {
      username = home-manager.lib.homeManagerConfiguration {
        pkgs = nixpkgs.legacyPackages.x86_64-linux;

        # ...

      };
    };
  };
}

However, I recently came across another example of a Home Manager flake, which doesn’t use legacyPackages. It seems like a better way to organize it.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";

    home-manager.url = "github:nix-community/home-manager";
    home-manager.inputs.nixpkgs.follows = "nixpkgs";
  };

  outputs = { nixpkgs, home-manager, ... }@inputs:
    let
      pkgs = import nixpkgs {
        inherit system;
      };
      system = "x86_64-linux";
    in {
      homeManagerConfigurations = {
        username = home-manager.lib.homeManagerConfiguration {
          inherit system pkgs;

          # ...

        };
      };
    };
}

Assuming this layout is still valid and not something from the past, does it really do the same thing? Why use legacyPackages if you can just directly import nixpkgs into the configuration?

2

Good question!

The first approach where you access legacyPackages is actually more efficient and generally preferable, since you will be reusing the already existing instance of nixpkgs.

The second approach is less efficient because you are creating a new nixpkgs instance, meaning that because of the import statement, nix will re-evaluate the code in nixpkgs’ default.nix and keep a separate instance in memory, in addition to the one that was already passed to your outputs function and that’s also used by home-manager (because of how you configured the inputs, which is generally what you’d want).

The fact that the package set is called legacy, is not because its use is deprecated or such, it’s because the packages output in a flake is only supposed to contain derivations, but nixpkgs’ top level expression also contains other things (like functions and attrsets containing derivations), and so if we’d put all of that in packages, nix flake check would complain. And so a separate output was created that doesn’t have this requirement.

You can read more about the issue with creating multiple nixpkgs instances here: 1000 instances of nixpkgs

1 Like
3

That is only a problem when the dependency flake already uses legacyPackages. home-manager.lib.homeManagerConfiguration requires passing a Nixpkgs instance explicitly so it does not suffer from the issue.

You may encounter it when you use home-manager’s package outputs but that does not appear to be the case here.

In my opinion, dependency injection is a good idea and outputs like packages that do not support it are ugly and should only ever be used for ad-hoc commands nix run. Pulling packages into system configurations is more cleanly achieved with overlays (pure ones, not just superimposition of packages). The downside is that dependency then loses the ability to pin Nixpkgs.

Also since legacyPackages is already instantiated, it does not allow you to parametrize the Nixpkgs instance, e.g. setting config.

Well, Nix is a lazy language so if you do not use legacyPackages anywhere else in the evaluation, you will still only have a single instance.

1 Like