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

ovoverlay import mechanics don't seem to allow file name attribute discrepancy and also do not distinguish between nixos and master #76

Closed
blaggacao opened this issue Jan 11, 2021 · 3 comments · Fixed by #78 or #77

Comments

@blaggacao
Copy link
Contributor

blaggacao commented Jan 11, 2021

Because of
https://github.com/nrdxp/nixflk/blob/d0fe508da20695bd72c1a5eebd3cb113778366ac/flake.nix#L51

in conjunction with

https://github.com/nrdxp/nixflk/blob/d0fe508da20695bd72c1a5eebd3cb113778366ac/lib/utils.nix#L89-L92

https://github.com/nrdxp/nixflk/blob/d0fe508da20695bd72c1a5eebd3cb113778366ac/overlays/kakoune.nix#L13

would not be made available in pkgs.

In general, I'm not sure if "too much magic" here is really a win or if overlays could be managed in a more transparent manner.

I really like the way how flake-utils's simpleFlake commands name spacing (see #60).
That approach doesn't limit overlaying "stock" packages, though, through a little extra helper that would read overlays from a non name spaced portion of the overlay file:

final: prev: {
   nixflk = {}; # name spaced overlays -- sharing friendly as `self.overlay` (namespaced, too!)
   utillinux = prev.util-linux; # non name spaced overlays -- ought not to be  exported as `self.overlay` (sic!) but available under `self.overlays.utillinux`
}

On the other hand it seems that we need a way to target an overlay either at master or at nixos, since on the contrary we expose the users to nasty and unexpected side effects of the implementation detail that genPackages targets both branches.

@blaggacao
Copy link
Contributor Author

As for overlays on master: Couldn't we just drop overlays application on master? It seems there is no good UX that doesn't cause loads of troubles down the road.

@blaggacao blaggacao changed the title ovoverlay import mechanics don't seem to allow file name attribute discrepancy ovoverlay import mechanics don't seem to allow file name attribute discrepancy and also do not distinguish between nixos and master Jan 11, 2021
@nrdxp
Copy link
Collaborator

nrdxp commented Jan 11, 2021

We definitely need to simplify the semantics here. Originally, the name discrepency was on purpose to allow for "utility" overlays, such as kakoune-config that are available inside the NixOS config, but not as an export.

In general though, I want a simpler and more robust overlay interface. For example,
https://github.com/nrdxp/nixflk/blob/d0fe508da20695bd72c1a5eebd3cb113778366ac/hosts/default.nix#L70-L74

is very brittle and easy to break or misuse.

@nrdxp nrdxp closed this as completed in #77 Jan 12, 2021
@blaggacao
Copy link
Contributor Author

Indeed it is: 😉

at: (72:22) in file: /nix/store/x1jl3zbjvds5x8yvf0vanpxs3p5zfpgx-source/hosts/default.nix

    71|                 overlay = pkg: final: prev: {
    72|                   "${pkg.pname}" = pkg;
      |                      ^
    73|                 };

attribute 'pname' missing
(use '--show-trace' to show detailed location information)

Pacman99 pushed a commit that referenced this issue Feb 23, 2022
In several places `mkFlake` assumes an valid value is set, here.

fixes: #76
Pacman99 pushed a commit that referenced this issue Feb 26, 2022
In several places `mkFlake` assumes an valid value is set, here.

fixes: #76
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants