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

Initialize nixos module system. (translators only) #249

Merged
merged 8 commits into from
Aug 16, 2022
Merged

Conversation

DavHau
Copy link
Member

@DavHau DavHau commented Aug 12, 2022

This initializes the structure for a potentially fully nixos modules based dream2nix framework.
For now only the translators and some related functionality is migrated as a test to allow for reviews.

In the future, further functionality could/should be migrated to /src/modules.

Why we want this?:

  • type checked internal and external interfaces
  • automatically documented interfaces
  • better extensibility of the framework
  • simplify structure of the dream2nix source code

Concerning the file structure:

The idea is that /src/modules is a flat structure of directories. It should be easy to find the source of an option definition by knowing the option attribute path.
For example the option functions.translators.{something} can be found in /src/modules/functions.translators
Every file in /src/modules/{category} should contain an interface.nix and an implementation.nix.
This should make it easy to quickly find the interface definition as a contributor.

Transition phase:

With this, now the framework is a mix of nixos-modules and not nixos-modules. That is a bit ugly, but we have no better way other than slowly transitioning to the new structure, and letting both old and new structure access each other.

Currently the nixos modules pieces, can access the old non-module pieces by using the specialArgs dlib and callPackageDream.
The non nixos-modules pieces can access the modules via the framework attribute which is brought in scope via callPackageDream.

@yusdacra It would be great if you could review this since you had implemented the current custom module loading logic.
Now is the time to really optimize the new structure, before we decide to move more stuff over.

@infinisil In case you have time to have a quick look at this, it would be great. If not, don't worry.

src/default.nix Show resolved Hide resolved
src/modules/functions.subsystem-loading/interface.nix Outdated Show resolved Hide resolved
src/subsystems/translators.nix Show resolved Hide resolved
- add documentation to the subsystem-loading interface
- expose evaled modules publicly via `framework`
- add option config.modules to allow users to include their own modules
- update examples for extending dream2nix
Copy link
Member

@yusdacra yusdacra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why the unit tests fail but that should be fixed, other than that it's LGTM

@DavHau DavHau merged commit d676f09 into main Aug 16, 2022
@DavHau DavHau deleted the translator-modules branch August 16, 2022 11:47
@johnae johnae mentioned this pull request Aug 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants