-
-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose the PackageDef's #15
Comments
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 Or maybe 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 |
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.)
The text was updated successfully, but these errors were encountered: