Open tomberek opened 8 months ago
Hey, thanks for reaching out!
As for the proposal, I'd be interested in what use cases this enables or makes cleaner or more performant (though that should probably go in the RFC). The nixpkgs model of define with function, export package, and user can override has not been something that has bothered me yet. To be clear, I don't mean this as a point against it, but rather something I'd want to see clarified in the RFC. Another question would be how nix tooling is expected to interact with it.
I do like encouraging more use of packages from dependencies with ones own pkgs set, rather than using packages directly from flakes with that flake's pkgs as dependencies. This can be done with overlays, but some prefer to avoid overlays (though those concerns would be fixed by lazy attr names).
Once there is an RFC, I could add an experimental module for it, and if the RFC is accepted, I would add non-experimental support.
Is there common terminology for package definitions? I think I had seen them called package definitions somewhere, but not sure. If there is common terminology for it, would be good to know.
To do this currently would also be pretty easy:
outputs.packageDefs = config.packages;
Setting the above would export the definitions.
Letting something like nix build nixpkgs --recipe ./recipe.nix
work would be cool too, and easily allow an arbitrary file with one of these definitions to be build with inputs from an arbitrary flake reference.
Or maybe nix build myflake#recipe --pkgs nixpkgs
?
My personal flake has legacyPackages exported with all my custom packages and overrides, so would like to be able to build another flake's package with my pkgs set.
One thing that would be of great benefit from the lang side would be to be able to distinguish a package definition from a function that takes the package set. This would involve functionArgs also returning whether the function has a ...
arg. I.e. { a, b }: null
vs { a, b, ... }: null
. That way it is easier to determine if its intended to be called with callPackage or the whole package set. Currently there is no way to distinguish the two, even if they differ in behavior. It is also an error to call the former with the full set so can't use tryEval.
Please consider exposing the PackageDef's as a top-level flake output. This means prior to performing a fixed-point operation, before calling callPackage.
You are allowing people to define their flake using an attrset of PackageDefs (i usually use the term "recipe"). But I'd like people to be able to access them directly as an output as well, not only in the wrapped form in overlays.default.
This makes sharing and re-using them much easier.
(Likely will have an RFC soon to propose adding a new top-level output to the known flake schema. And I'm socializing this around with the various flake libraries.)