| Title | Author | Discussions-To | Status | Type | Topic | Created |
|---|---|---|---|---|---|---|
Allow for users to pass modules to pkgs.config |
jonringer |
Draft |
Standards Track |
Packaging |
2024-10-17 |
In addition to the language overlay proposal,
the ability to configure the language overlays should also not be burdensome to compose.
The solution here would be to extend the existing pkgs.config evaluation to include
many modules which can be passed to its creation. The goal is to allow for both
the overlays (e.g. core-pkgs) to pass modules describing their overlays in addition
to the overlays supplied by the user.
The totality of https://github.com/jonringer/language-specific-config-overlays-proposal:
@@ -27,6 +27,9 @@
, # Allow a configuration attribute set to be passed in as an argument.
config ? {}
+, # Allow for users to pass modules for the evaluation of pkgs.config
+ modules ? []
+
, # List of overlays layers used to extend Nixpkgs.
overlays ? []
@@ -93,7 +96,7 @@ in let
_file = "nixpkgs.config";
config = config1;
})
- ];
+ ] ++ modules;
class = "nixpkgsConfig";
};For the "capstone" pkgs repo, the composition of all sub-overlays would roughtly follow:
# default.nix in pkgs repo
{ system ? builtins.currentSystem
, modules ? []
, ...
}@args:
let
# pins to language repos and core-pkgs
pins = import ./pins.nix;
# stdenv should rarely change, as pkgs.stdenv is largely created in core-pkgs
stdenv = ...;
filteredAttrs = builtins.remoteAttrs [ "modules" "system" ] args;
in
import stdenv ({
inherit system;
modules = let
poly-modules = builtins.mapAttrs (_: v: import "${v}/pkgs-module.nix") pins;
in poly-modules ++ modules;
} // filteredAttrs)Each poly-repo would just expose a /pkgs-module.nix which would contain all information
about the language specific repos to the package set.
A general flake exposing a python package could be expressed as:
# flake.nix
let
pythonOverlay = final: _: {
my-pkg = final.callPackage ./package.nix { };
};
top-level-overlay = final: _: {
my-pkg = with final.python3.pkgs; toPythonApplication my-package;
};
pkgs-module = {
overlays.pkgs = [ top-level-overlay ];
overlays.python = [ pythonOverlay ];
};
in flake-utils.eachDefaultSystem (system: rec {
legacyPackages = import core-pkgs {
inherit system;
modules = [ pkgs-module ];
};
packages.default = legacyPackages.my-pkg;
modules = {
pkgs = pkgs-module;
};
})The benefit here is that the package is now available for each pkgs.pythonX version
as well as the module is available for downstream flakes/repos to also consume in an easy fashion.
For example:
# flake.nix
inputs.foo = "github:....";
...
{
legacyPackages = import core-pkgs {
inherit system;
# This would now apply the python and top-level overlay from foo as well
modules = [ foo.modules.pkgs my-repo-module ];
};
}- To remove ambigiuity with system module eval, should the attr be named
pkgsModulesinstead? - What to do with legacy
configoption?- Most likely keep for backwards compatibility with people wanting to interop with nixpkgs
- Implement
options.overlays.<languagefor each language repository - As part of system mdoule eval, a
nixpkgs.modulesoption should be addednixpkgsshould be renamed to a more generic term