Derivation builders and package sets

[mrtnvgr]

Hi,

How to add custom package sets (just like python3Packages in nixpkgs) and derivation builders (e.g. fetchzip, rustPlatform.buildRustPackage...)?

[roberth]

It's somewhat of an unanswered question in terms of the de facto schema, but legacyPackages allows for nested attrsets by virtue of its intentional lack of specification.
Derivation builders are functions, so you could put them in a lib output. There's also a bundlers output attribute, but iirc it requires a specific kind of argument (one package?) that might not always be what you want for your own derivation creating functions.

I would probably re-expose some of the top level module arguments like getSystem

{ lib, flake-parts-lib, getSystem, ... }:
{
  flake.lib.getSystem = getSystem;
}

also we should have a similar one that sets pkgs:

flake-parts/extras/easyOverlay.nix

Lines 53 to 57 in 52a2cae

	perSys = (getSystemIgnoreWarning system).extendModules {
	modules = [
	{
	_file = "flake-parts#flakeModules.easyOverlay/overlay-overrides";
	_module.args.pkgs = lib.mkForce prev;

Not sure what to call it. forPkgs sounds like a flip map-like function. withPkgs suggests a callback like withSystem. setPkgs? atPkgs? havingPkgs? All sounds worse. Maybe forPkgs isn't so bad.
Or maybe a configure function that you can pass a whole module, including _module.args.pkgs = lib.mkForce mypkgs;.

Independent of all that, we should also have an opt-in bundlers module in extras/ that implements the nix bundle interface.

[mrtnvgr]

How can I add the packages right now, before these features will be added? I can't wrap my head around this. When I include them in packages, I get an error that they are not of a package type. Can I remove type checking in a patch for the flake-parts? I don't care about the types much in this case. Thank you for an answer :)

[roberth]

The packages are meant to be a flat set of packages according to nix flake check and some other sources. Not much we can do about that. legacyPackages doesn't have any restrictions like that, so you could use that attribute instead.

Turns out bundlers was already a thing; just didn't make it onto the docs site. fixed. It's probably not right for arbitrary builders though.

So flakes does not have great answers for this out of the box.
You could however create your own flake.lib and refer to the getSystem/withSystem module arguments for constructing system-dependent stuff inside of it.

Perhaps something like this:

# mkFlake module or imported flake parts module file
{ lib, flake-parts-lib, getSystem, ... }:
{
  options.perSystem = flake-parts-lib.mkPerSystemOption (
    { pkgs, ... }:
    {
      options.builders = lib.mkOption { };
      config.builders = {
        foo = { bar, baz }: pkgs.stdenv.mkDerivation ...;
      };
    }
  );
  config = {
    flake.lib.getBuilders = system: (getSystem system).builders;
  };
}