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

Separate flake for nixpkgs dependency #169

Open
LiGoldragon opened this issue Jun 13, 2023 · 1 comment
Open

Separate flake for nixpkgs dependency #169

LiGoldragon opened this issue Jun 13, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@LiGoldragon
Copy link

In order to let the nixpkgs API develop itself as separate module. That sounds like the direction this project is about. Is that planned and or interesting? Would a separate repo work better, or a local sub-flake? I would think the first option cleaner and lighter when using core-only. Will be working on a separate nixpkgs abstraction in a standalone repo for now, probably coupled with a nixpkgs module at first, to keep the concept in one place. Cheers.

PS. Watch for that Pluto contra-parallel Sun, it's still on for a few weeks, feels as if the fabric of reality is resisting the Heart. It will pass ... :)

@roberth
Copy link
Member

roberth commented Jun 13, 2023

Cool. I also wrote this in the meantime

It's not flake-parts-specific, or at least not anymore. It adds a generic module that provides the basic options; no attrsOf. It's sufficient for importing into perSystem, and I've had the realization that importing into perSystem has the benefit of improving laziness of input fetching when perSystem is never used (but for example flake.lib or flake.nixosModules is). This is likely an unlikely benefit, and I hope importing into both top level and perSystem won't cause too much confusion.
So there's some laziness benefit to having a separate nixpkgs module that doesn't need to load a whole version of Nixpkgs just to be ignored later. I think one particularly strong case is the easyOverlay module, as it makes the nixpkgs input completely useless, and so loading it unconditionally is wasteful, and importing in perSystem (instead of a top level module) doesn't change anything about that.

tl;dr separate nixpkgs caller module still good!

@roberth roberth added the enhancement New feature or request label Jan 29, 2024
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