-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
[WIP] Separate NixOS lib and nixpkgs lib #19153
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
Conversation
@ericsagnes, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @nbp and @shlevy to be potential reviewers. |
Any opinions on this? |
The idea at least seems good to me, but I haven't done much nixos/* stuff, so better if someone else looks at it as well. |
I think this change would have made sense when nixpkgs and NixOS were in separated repository. |
As it was only linked in the description and easy to miss, bellow is the quote from @edolstra comment that motivated this PR:
I do agree with that, but I think that it could be useful to have some NixOS specific functions easily available from external projects, like testing related functions. Making a NixOS specific library that could be imported with I hope this can help to clarify the motivation. |
I've found the module system nice to be able to use outside of NixOS, for example in defining a user environment (see https://github.com/rycee/home-manager for instance), so I'd like to see it continue to be available from the main Nixpkgs |
I have totally forgot about this one. I agree that it is easy to use nix lib from outside of nixpkgs, and I do that in a few of my personal projects. Anyway, closing as this has been open for too long. |
Motivation for this change
This was motivated by this comment.
The ultimate goal of this PR is to be able to include NixOS lib functions in an easy manner for custom projects, eg
with import <nixpkgs/nixos>; lib....
.An other objective is to have a clearer separation between nixos and nixpkgs functions.
Until now, only nixpkgs had a lib, and NixOS related functions were part of this lib, directly called via
imports
(eval-config) or directly defined in files (test related functions).For a better separation and cleaner namespaces, this PR create a new lib to nixos, that can be called with
with import <nixpkgs/nixos/lib>; ...
orwith import <nixpkgs/nixos>; lib....
and move the functions that has nothing to do with nixpkgs in the nixos library.This is a work in progress, and this aims to be as much backward compatible as possible.
nixpkgs lib side
options
,types
,modules
have moved to nixos lib, but each file (lib/options.nix
, ...) is still present to not break any direct imports (eg,import <nixpkgs/lib/options.nix>
) that users might have in their setups.The nixos lib, can be accessed via the
lib.nixos
namespace. So if options functions must be used in nixpkgs context, they can be accessed withlib.nixos.options
.Note that there is no trace of usage of options, types and modules in the nixpkgs only source, so the new namespace should not break things.
nixos lib side
A lib top level attribute was added to ./nixos that can be used with "with import <nixpkgs/nixos>; lib..." or "with import <nixpkgs/nixos/lib>;".
This lib includes previous nixpkgs lib
options
,types
andmodules
.The nixpkgs lib is in the namespace
lib.nixpkgs
AND at top-level.This is the
lib
that is used in the module system, so having nixpkgs lib at top level is required to not break modules code that expect nixpkgs lib functions to be accessible from lib.This is in early state and will require more extensive testing to be sure nothing break it is much backward compatible as possible before being mergeable.
In current state, this can build the manual and a simple config via VM.
Feedback is welcomed.
cc @edolstra