Skip to content
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

Open
tomberek opened this issue Feb 28, 2024 · 3 comments
Open

expose the PackageDef's #15

tomberek opened this issue Feb 28, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@tomberek
Copy link

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.)

@accelbread
Copy link
Collaborator

accelbread commented Feb 29, 2024

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.

@accelbread
Copy link
Collaborator

accelbread commented Feb 29, 2024

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.

@accelbread accelbread added the enhancement New feature or request label Feb 29, 2024
@accelbread
Copy link
Collaborator

accelbread commented Feb 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants