Nixpkgs module

[roberth]

Prototype a more extensive Nixpkgs module in flake-parts before perhaps eventually doing #41

https://twitter.com/ldesgoui/status/1592576468789628928

[srid]

Could we have more than one pkgs as a result? For, eg., native pkgs and a rosetta pkgs (on aarch64-darwin).

[roberth]

Good idea. The root nixpkgs.* options could be permanent aliases for nixpkgsSets.pkgs or something.

[roberth]

For Rosetta, you can already get a pkgs via getSystem and/or withSystem. Those will also give you access to your own packages for that system. The feature still makes a lot of sense for having different versions of Nixpkgs, but for mixed-system and cross, it'd be better to use and improve the perSystem infrastructure.

[Atry]

I would just use https://github.com/NixOS/nixpkgs/blob/3b4e70e987a42792196294560a233d285b1c1d10/nixos/modules/misc/nixpkgs.nix

    ml-ops.inputs.flake-parts.lib.mkFlake { inherit inputs; } {
      perSystem = { pkgs, system, ... }:
        {
          imports = [
            "${inputs.nixpkgs}/nixos/modules/misc/nixpkgs.nix"
          ];
          nixpkgs = {
            hostPlatform = system;

            # other options, e.g. 
            # config.allowUnfree = true;
          };
       };
    }

[roberth]

I'd previously opened https://github.com/NixOS/nixpkgs/pull/231940 with the idea to import from that, but I've since realized that Nixpkgs needs an exception, because imports will fetch it eagerly, and that's a problem for such a large dependency, when it might not even be used (e.g. easyOverlay use case; see https://github.com/hercules-ci/flake-parts/pull/147#issuecomment-2138376065)

I'm sorry to have gone back and forth on this, but at least we didn't commit to a mistake in the meanwhile.

Aforementioned Nixpkgs makes a number of improvements which we should adopt in the flake-parts Nixpkgs module.

It could look as follows:

• flake-parts.modules.flake.pkgs is a new module
• it declares in perSystem.nixpkgs.<name>:
  • hostPlatform (default: system)
  • buildPlatform (build elsewhere for cross)
  • pkgs (alias for _module.args.pkgs)
  • overlays
  • config
  • source (default: inputs.nixpkgs)
• <name> causes _module.args.<name> to be set
  • if enabled?
• it does not have the legacy options system, localSystem or crossSystem
• the perSystem.pkgs option is an alias for perSystem.nixpkgs.pkgs
  • or should this be the other way around? That way it's more NixOS compatible. e.g. perSystem.nixpkgs.config.allowUnfree = true; or pkgs.pkgs-unstable.source = inputs.nixpkgs-unstable;

[tie]

It’d also be nice to have readOnlyPkgs module, similar to what we have for NixOS.

[roberth]

overlays must be disallowed by default, because they are simply too risky, especially as otherwise any module could define any attribute in it, affecting all callPackage, without the flake author being aware of this happening.

Even an attribute as innocent as sources (convenient, not a package name) will cause some packages to fail to evaluate with an obscure error. Very hard to troubleshoot, and not worth the "convenience" at all.

We have better ways to convey values, such as flake-parts-lib.importApply, withSystem, etc, which do not create this risk of obscure silent name collisions.