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

perSystem: add a default value for systems #28

Closed
wants to merge 1 commit into from

Conversation

srid
Copy link
Contributor

@srid srid commented May 28, 2022

Resolves #25 - specifically #25 (comment)

Copy link
Member

@roberth roberth left a comment

Choose a reason for hiding this comment

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

After some discussion and researching the flakeExposed attribute, I don't think we should have this default here. Hang tight for a solution though.

The flakeExposed attribute is a very recent addition to Nixpkgs, which makes me a bit uneasy about the stability of this (while acknowledging that flakes are entirely unstable).

Setting this default also goes against how Eelco intended systems to be used: to provide known-working attributes. By setting this default, we remove the "known" aspect and more likely than not, the "working" aspect. That would be bad for your users and all flake-parts users.

flake-parts is intended to be a common core for many distributed expressions to interoperate. Bringing an opinionated default into the core defeats its purpose as a unifying interface, as it gives others reasons to reject it.

As an example, I've only accepted the default pkgs because I expect almost everyone to agree on its definition and the existence of a pkgs module argument being a unifying force, until a better solution is applied (nixpkgs.flakeModules.pkgs, TBD).

But, while I'm sorry for the bad news part, there is a solution, which is to create your own module of opinionated defaults. If this single line is really important, presumably you have it in more than one repo, so it might make sense to create a module with personal defaults in a separate repo. You can use that not just to set the default systems, but also a default Nix formatter with pre-commit-hooks-nix for example.

@srid
Copy link
Contributor Author

srid commented May 28, 2022

@roberth No worries.

If this single line is really important, presumably you have it in more than one repo, so it might make sense to create a module with personal defaults in a separate repo. You can use that not just to set the default systems, but also a default Nix formatter with pre-commit-hooks-nix for example.

Is there documentation on 'creating modules for flake-parts'? The linked PR has options and config. What are these? Are there other fields? Its template flake sets pre-commit.settings but when using it, instead it accesses config.pre-commit..; why is that? I suppose my (beginner) questions are also relevant for srid/haskell-template#21

@roberth
Copy link
Member

roberth commented May 28, 2022

Is there documentation on 'creating modules for flake-parts'?

No docs for writing flake-parts modules specifically yet, but the general structure like config, options, mkOption and the types is the same as that of NixOS modules, which are documented in the NixOS manual.

Instead of NixOS options like services.<name>.*, boot.* and systemd.*, we have flake options.

Its template flake sets pre-commit.settings but when using it, instead it accesses config.pre-commit..; why is that?

When you write a simple module, it's often possible to omit config.. These modules are equivalent

{
  systems = ["x86_64-linux"];
}
{
  config.systems = ["x86_64-linux"];
}

This is also part of the reason why you don't have to use config in submodules.

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.

Add mkSimpleFlake?
2 participants