Skip to content

Conversation

@Frontear
Copy link
Owner

@Frontear Frontear commented Sep 9, 2024

The first of these changes is that I removed nixos-cosmic and lix from
flake inputs. For nixos-cosmic, I simply wasn't using it, so building it
every time was a complete waste of my time. For Lix, I figure I can
simply follow whatever nixpkgs has, I don't need the absolute bleeding
edge lix build.

I've returned to home-manager. Why did I return to hm? Simple, to reduce
"re-inventing the wheel". My whole my.users stuff had two grand problems,
one was that it wasn't really user independent given my personal configs
were baked right into the module, and that it essentially did what hm is
already doing, just reinventing. This is arguably very wasteful, and so
I've opted to simply go back to hm, but be a bit more strict.

  1. Checks through osConfig, to ensure adequate system values are set.
  2. Use my own modules, and avoid the shitty hm ones. Not all are shitty,
    but quite a few are.
  3. Make users independent of hosts, and set any required system state
    at the users entrypoint.

I should've broken these up into multiple PRs, but now I made too many
changes at once, mb.

The first of these changes is that I removed nixos-cosmic and lix from
flake inputs. For nixos-cosmic, I simply wasn't using it, so building it
every time was a complete waste of my time. For Lix, I figure I can
simply follow whatever nixpkgs has, I don't _need_ the absolute bleeding
edge lix build.

I've returned home-manager and impermanence. home-manager is linked via
a very simple entrypoint right now, but impermanence hasn't. Why did I
return to hm? Simple, to reduce "re-inventing the wheel". My whole
`my.users` stuff had two grand problems, one was that it wasn't really
user independent given my personal configs were baked right into the
module, and that it essentially did what hm is already doing, just
reinventing. This is arguably very wasteful, and so I've opted to simply
go back to hm, but be a bit more strict.

1) More parity with osConfig, to ensure adequate system values are set.
2) Use my own modules, and avoid the shitty hm ones. Not all are shitty,
   but quite a few are.

I've also gone ahead and removed all overlays. Nix as a buildInput is
shockingly rare, and overlaying it is pretty stupid. It only serves to
taint pkgs.

Modules have been moved to **modules/nixos**, and a
**modules/home-manager** now exists.
There's a lot of leftover/stray stuff because I'm trying to NOT break
DESKTOP-3DT4F02, but I might end up saying fuck it and breaking it
anyways. We are in a PR after all.
I'm deleting out modules, which has intentionally broken DESKTOP. I'll
fix it before I merge this PR, of course.
Took the time to make users/frontear/programs recursive import.
Hell I actually might bring that lib function back.
There's a special reason I chose to do this. The home-manager
persistence module has to leverage user-space tools for mounting. This
is unfavourable but an unfortunate issue because home-manager is, like
I've said before, a Nix tool, not a NixOS tool. Therefore it doesn't
allow leveraging the powers of NixOS activation and makes the module
provided worthless. As a result, I am re-using my own.
I had to do them all in one swoop or else zsh would've been left
dangling, since so many different modules mess with it.
DESKTOP evaluates correctly, though I don't know 100% sure if it
actually works works.
provided they follow the templated behaviour
Deduplicates common values, similar to what I've done for
mkNixOSConfiguration.
This has a bit less use but is still relevant so keep it I shall
@Frontear Frontear merged commit add5128 into main Sep 9, 2024
@Frontear Frontear deleted the return-to-nix-community branch September 9, 2024 18:56
Frontear added a commit that referenced this pull request Sep 10, 2024
See MR #7 for why I decided to do this.
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.

2 participants