Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Heavy split and refactor of flake.nix #1

Open
wants to merge 1 commit into
base: external
Choose a base branch
from

Conversation

deliciouslytyped
Copy link

@deliciouslytyped deliciouslytyped commented Aug 8, 2022

I didn't look at module.nix

pr for code review @gytis-ivaskevicius

resolveOverlays = first: overlays: with nixpkgs.lib; let
# Passing inputs here means overlays can be called with the standard signature
# but still be parametrized with flakes, maintaining composability.
overlay' = flip (composeManyExtensions ([ (final: prev: { inherit inputs; }) ] ++ overlays));
Copy link
Member

Choose a reason for hiding this comment

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

What is the reason for flipping overlay arguments?

Copy link
Member

Choose a reason for hiding this comment

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

And cant we just partially apply overlays for inputs instead?
Like having function overlay :: inputs -> final -> prev -> attrs and call it overlay inputs which results in overlay :: final -> prev -> attrs

'';
};
};
mkSystem = system: modules: nixpkgs.lib.nixosSystem { inherit system modules; }; # TODO does the system argument make sense?
Copy link
Member

Choose a reason for hiding this comment

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

Yes, its system dependent

};
mkSystem = system: modules: nixpkgs.lib.nixosSystem { inherit system modules; }; # TODO does the system argument make sense?
in {
overlays.default = import ./nix/overlay.nix;
Copy link
Member

Choose a reason for hiding this comment

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

Reference to comment about passing inputs to overlay, this is how you'd do it:

Suggested change
overlays.default = import ./nix/overlay.nix;
overlays.default = import ./nix/overlay.nix inputs;

};
});
# Expose the module for use as an input in another flake
nixosModules.liberaforms = callModule ./nix/module.nix;
Copy link
Member

Choose a reason for hiding this comment

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

Not sure why are you performing explicit inputs passing to modules but I'm sure that it can be avoided

# Set the default package
// {default = self.packages.${system}.liberaforms;}
packages = genSystems (system:
let attrs = resolveOverlays pkgsFor.${system} [ (import ./nix/overlay.nix) ];
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
let attrs = resolveOverlays pkgsFor.${system} [ (import ./nix/overlay.nix) ];
let attrs = resolveOverlays pkgsFor.${system} [ self.overlays.default ];

@@ -26,7 +22,7 @@ in {

package = mkOption {
type = types.package;
default = self.packages.${pkgs.system}.default;
default = packages.default;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
default = packages.default;
inherit (packages) default;

@@ -182,7 +178,7 @@ in {
after = ["network.target" "postgresql.service"];
requires = ["postgresql.service"];
restartIfChanged = true;
path = with pkgs; [postgresql_11 liberaforms-env openssl];
path = with pkgs; [postgresql_11 penv openssl];
Copy link
Member

Choose a reason for hiding this comment

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

nixpkgs already has PostgreSQL service defined, we just need to configure it. no need to define a new one

Comment on lines +1 to +5
final: prev:
(with builtins; seq ((hasAttr "inputs" prev) || throw "If you are calling this directly, make sure the overlays have an `inputs` attribute conforming to the flakes interface."))
(let
packages = final.inputs.self.packages.${prev.system};
in {
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
final: prev:
(with builtins; seq ((hasAttr "inputs" prev) || throw "If you are calling this directly, make sure the overlays have an `inputs` attribute conforming to the flakes interface."))
(let
packages = final.inputs.self.packages.${prev.system};
in {
inputs: final: prev:
{

There is never a reason to use packages in overlays. Please use prev argument instead

Copy link
Author

Choose a reason for hiding this comment

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

I'm...not even sure why that's there. That should almost definitely be final.

${filteredReq}
${extraReq}
'';
in final.inputs.mach-nix.lib.${prev.system}.mkPython { inherit requirements; };
Copy link
Member

Choose a reason for hiding this comment

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

Please avoid using final so much

Copy link
Author

Choose a reason for hiding this comment

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

Final is the whole point of using overlays though.

Comment on lines +37 to +45
checkPhase = ''
source ${./test_env.sh.in}
initPostgres $(mktemp -d)

# Run pytest on the installed version. A running postgres database server is needed.
(cd tests && cp test.ini.example test.ini && pytest -k "not test_save_smtp_config") #TODO why does this break?

shutdownPostgres
'';
Copy link
Member

Choose a reason for hiding this comment

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

Consider moving this to passthru.tests

@fufexan
Copy link
Member

fufexan commented Aug 8, 2022

I generally agree with Gytis here. It feels like these changes overcomplicate the code instead of simplifying it, even though they split it up more.

Also, one question: what does composability mean here and why should we care for it? In my approach I haven't used a single final and don't think users would need to either.

@deliciouslytyped
Copy link
Author

deliciouslytyped commented Aug 8, 2022

My rather bad explanation is it means you can take things and build / combine more things out of them(, without having to fight them to fit). Kind of the inverse of reductionism.

It!s kind of the opposite of everything being tightly coupled and hard to use anywhere else.

@fufexan
Copy link
Member

fufexan commented Aug 11, 2022

I've applied a lot of changes from here into master. Thanks @deliciouslytyped for the refactor!

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants