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

API Discussions #232

Closed
wants to merge 7 commits into from
Closed

API Discussions #232

wants to merge 7 commits into from

Conversation

blaggacao
Copy link
Contributor

@blaggacao blaggacao commented Apr 7, 2021

API.md Outdated
Comment on lines 114 to 115
, sharedModules ? [ ]
, sharedOverlays ? [ ]
Copy link
Contributor Author

@blaggacao blaggacao Apr 7, 2021

Choose a reason for hiding this comment

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

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.

API.md Outdated
Comment on lines 126 to 128
# TODO
, suites
, hosts
Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

Comment on lines +153 to +154
, sharedModules ? [ ]
, sharedOverlays ? [ ]
Copy link
Member

Choose a reason for hiding this comment

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

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".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link

@gytis-ivaskevicius gytis-ivaskevicius Apr 8, 2021

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@blaggacao blaggacao Apr 8, 2021

Choose a reason for hiding this comment

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

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

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

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

David Arnold added 3 commits April 6, 2021 22:43
- 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.
Copy link

@gytis-ivaskevicius gytis-ivaskevicius left a comment

Choose a reason for hiding this comment

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

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/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.

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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. 😉

Copy link

@gytis-ivaskevicius gytis-ivaskevicius Apr 8, 2021

Choose a reason for hiding this comment

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

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

Comment on lines +16 to +21
```nix
concept1 = ./concept1;
concept2 = ./concept2;
concept3 = { "..." = "..."; };
concept4 = [];
```

Choose a reason for hiding this comment

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

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 = []'
}

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

Choose a reason for hiding this comment

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

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

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

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

@blaggacao blaggacao Apr 8, 2021

Choose a reason for hiding this comment

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

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

Comment on lines +154 to +165
, 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;
}

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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?

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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 😄
@blaggacao blaggacao changed the base branch from core to develop April 22, 2021 00:03
@bors bors bot closed this May 15, 2021
@bors bors bot deleted the branch divnix:develop May 15, 2021 04:25
@blaggacao blaggacao deleted the api/specs branch May 19, 2021 23:38
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.

4 participants