API Discussions #232

blaggacao · 2021-04-07T01:46:04Z

blaggacao · 2021-04-07T01:53:54Z

API.md

+, sharedModules ? [ ] 
+, sharedOverlays ? [ ]


fup only differentiates on the axis of shared vs individual (per host profile).
Since devos also aspirates a sharing model, we need to know which modules to re-export for others to consume.

The naming here is not the best, ideally we could find a naming that clearly reflects both dimensions, without becoming an over-complicated matrix.

blaggacao · 2021-04-07T02:03:00Z

API.md

+  # TODO
+  , suites
+  , hosts


Not sure what we should expect from suites and hosts importers here...

Pacman99 · 2021-04-07T03:20:02Z

API.md

+, sharedModules ? [ ] 
+, sharedOverlays ? [ ]


I would say call sharedOverlays just overlays and sharedModules something like internalModules. That makes it clear that those modules are only for simple things and they won't get exported. And theres no need to call it sharedOverlays if theres no "unshared overlays".

In theory, we have:

shared modules (for all hosts)

non-shared modules (for some hosts)

shared overlays (for all hosts)

non shared overlays (for specific hosts)

but also external shared modules and external host specific modules

and also external shared and unshared overlays

... in theory. We have to make a good cut, I guess.

sharedOverlays vs overlays - calling it overlays would mean a name conflict between abstraction and flake itself.

internalModules - I'd say naming could be better than that. Maybe something that actually represents that its auto imported to all the configurations?

Overall, I'm quite a fan of sharedXyz since naming is clear, more or less makes sense, and does not conflict with actual flake attributes

FWIW simpleFlake calls it preOverlays — since the order of application matters in overlays.

Pacman99 · 2021-04-07T03:25:00Z

API.md

+  self
+, defaultSystem ? "x86_64-linux"
+, supportedSystems ? flake-utils.lib.defaultSystems
+, name # or inputs, see: https://github.com/gytis-ivaskevicius/flake-utils-plus/issues/12


If namespacing is no longer a goal, name isn't necessary. inputs is also unecessary, because you can just use self.inputs.

I think it boils down to how foreign flakes should be consumed. So it's kind of a difficult normative call to make. As I argue in the linked issue, flake.nix have a relatively strict output schema. I only might speculate the intention was to also consume flake by them and not the en-globing corresponding input (not inputs!) object, itself.

- nixosUserProfiles is a bit clashing with hm modules, we might want to just combine them into nixosProfiles, and make a distinction on a template - ditch mkFlake' since its only raison d'etre was to showcase what importers would do to things.

gytis-ivaskevicius

Okay, first of all, the more I read name systemFlake the more i hate it :D

Second, If you guys were to create additional devos.nix file or something like that as part of fup for time being - I am fine with it. This might make life easier, especially in a prototyping stage.

gytis-ivaskevicius · 2021-04-08T08:33:43Z

API.md

+- `gytis/flake-utils-plus` is designed to be incorporated in upstream flake-utils. As the name suggests, it wraps and extends `flake-utils` for nixos related use cases.
+- `devos-lib` shall be another layer that wraps `flakes-utils-plus` and adds accoustomed devos amentities, such as:
+  - automagic importers, for pure convenience, but without prescribing a particular folder layout (that is something for devos templates to achieve).
+  - additional configuration generators, such as for `deploy-rs` or `home-manager` or other future integrations (eg. mobile nixos, etc) that we want to offer as a convenience.


I would be so down with implementing deploy-rs and HM as part of the flake-utils-plus ;)

At least deploy-rs currently has a dependency injected of a deploy.lib library function, though.

I still regard being dependency-free as a feature. 😉

oh yeah, I am planning to keep fup dependency-free :)

gytis-ivaskevicius · 2021-04-08T08:38:35Z

API.md

+```nix
+  concept1 = ./concept1;
+  concept2 = ./concept2;
+  concept3 = { "..." = "..."; };
+  concept4 = [];
+```


Not exactly relevant but having all attributes interpreted like so would be pretty cool:

{ concept1 = ./some/directory; # Evaluates to 'concept1 = { fileNameWithoutNixExtension = {...}; }' concept2 = ./someFile.nix; # Evaluates to 'concept2 = { "..." = "..."; }' concept3 = { "..." = "..."; }; # Evaluates to 'concept3 = { "..." = "..."; }' concept4 = []; # Evaluates to 'concept4 = []' }

gytis-ivaskevicius · 2021-04-08T08:41:48Z

API.md

+, hmProfiles ? { NAME = { 
+    modules = [ ];
+    extraArgs = { };
+    # what else makes sense, here?


I believe system is still required, also maybe having an option to pick which channel is used would be nice since a lot of people are running core system on stable, HM on unstable channels

gytis-ivaskevicius · 2021-04-08T08:44:32Z

API.md

+    input = "...";
+    overlaysBuilder = channels: [ (final: prev: { })];
+    config = { };
+    patches = [ ];


At this point I'm like "can we just pay some C++ nerd to properly implement channels patching as part of Nix binary instead" :D

Hm, actually that seems like a good venue. We could start by lobbying more heavily and probably Ma29 could lend us a hand.

x-ref NixOS/nix#3920

gytis-ivaskevicius · 2021-04-08T08:54:31Z

API.md

+, nixos ? {
+    modules = ./modules;
+    profiles = ./profiles;
+    specialArgs = { }; # https://github.com/gytis-ivaskevicius/flake-utils-plus/issues/13#issuecomment-814512835
+    hosts = ./hosts;
+    suites = ./suites;
+, hm ? {
+    modules = ./users/modules;
+    profiles = ./users/profiles;
+    specialArgs = { };
+    suites = ./users/suites;
+  }


hm.modules = ./abc; is not a valid syntax due to missing profiles/specialArgs/suites. I am not sure if thats intended.

The idea here is to take those values at face value & in a first step applying maybeImporters and only in a second step function instantiators, the latter passing all nescessary args around.

Does that make sense or did I misread your comment?

I mean the way default values are implemented - if hm.modules is defined - hm.profiles/hm.specialArgs/hm.suites must be manually defined as well

Ah! @Pacman99 in the meanwhile is an expert of validating, crosschecking and defaulting values via the module system.

I think it will be a mix of a:

coustom type

sane defaults

apply transformations

...

which has dual effect of increasing modesty 😄

checkpoint

141efa9

blaggacao force-pushed the api/specs branch from a807681 to 141efa9 Compare April 7, 2021 01:49

blaggacao commented Apr 7, 2021

View reviewed changes

some updates

f1ed2de

blaggacao mentioned this pull request Apr 7, 2021

Base for devos gytis-ivaskevicius/flake-utils-plus#2

Closed

Pacman99 mentioned this pull request Apr 7, 2021

Move flake implementation logic to lib #231

Merged

oversight from previous commit

7b93e33

Pacman99 reviewed Apr 7, 2021

View reviewed changes

David Arnold added 3 commits April 6, 2021 22:43

Agreement in principle reach on how to deal with escape hatches upstream

4f69777

Split it further

7153c92

gytis-ivaskevicius approved these changes Apr 8, 2021

View reviewed changes

gytis-ivaskevicius mentioned this pull request Apr 8, 2021

Add argument for default host attributes gytis-ivaskevicius/flake-utils-plus#19

Merged

blaggacao mentioned this pull request Apr 11, 2021

Providing an interface to nixpkgs.config #237

Closed

This was referenced Apr 12, 2021

Implement evalArgs for new API #238

Closed

Update evalArgs to match the new planned API #239

Merged

add mkFlakeDoc to pkgs-lib to build options doc #240

Closed

fix typo

0f656a8

which has dual effect of increasing modesty 😄

blaggacao changed the base branch from core to develop April 22, 2021 00:03

bors bot closed this May 15, 2021

bors bot deleted the branch divnix:develop May 15, 2021 04:25

blaggacao deleted the api/specs branch May 19, 2021 23:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

API Discussions #232

API Discussions #232

blaggacao commented Apr 7, 2021 •

edited

Loading

blaggacao Apr 7, 2021 •

edited

Loading

blaggacao Apr 7, 2021

Pacman99 Apr 7, 2021

blaggacao Apr 7, 2021

gytis-ivaskevicius Apr 8, 2021 •

edited

Loading

blaggacao Apr 8, 2021 •

edited

Loading

Pacman99 Apr 7, 2021

blaggacao Apr 7, 2021

gytis-ivaskevicius left a comment

gytis-ivaskevicius Apr 8, 2021

blaggacao Apr 8, 2021

gytis-ivaskevicius Apr 8, 2021 •

edited

Loading

gytis-ivaskevicius Apr 8, 2021

gytis-ivaskevicius Apr 8, 2021

gytis-ivaskevicius Apr 8, 2021

blaggacao Apr 8, 2021 •

edited

Loading

gytis-ivaskevicius Apr 8, 2021

blaggacao Apr 8, 2021

gytis-ivaskevicius Apr 8, 2021

blaggacao Apr 8, 2021

API Discussions #232

API Discussions #232

Conversation

blaggacao commented Apr 7, 2021 • edited Loading

blaggacao Apr 7, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gytis-ivaskevicius Apr 8, 2021 • edited Loading

Choose a reason for hiding this comment

blaggacao Apr 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gytis-ivaskevicius left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gytis-ivaskevicius Apr 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blaggacao Apr 8, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blaggacao commented Apr 7, 2021 •

edited

Loading

blaggacao Apr 7, 2021 •

edited

Loading

gytis-ivaskevicius Apr 8, 2021 •

edited

Loading

blaggacao Apr 8, 2021 •

edited

Loading

gytis-ivaskevicius Apr 8, 2021 •

edited

Loading

blaggacao Apr 8, 2021 •

edited

Loading