[–] 1 point 5 months ago

I usually prefer to use nix, as it's a real language and basically serves as macro language/preprocessor for the configs that don't have functions or such (obviously in this case Lua does) . So it gives me everything in one language (thank I generally kinda like), with proper highlighting, I can reuse code, and I can more easily cross reference between different services/apps.

That said, I didn't know hyprland was going to make this switch. I guess I finally have to go see if I will like niri.

  • source
  • [–] [S] 1 point 5 months ago (3 children)

    Ok, that seems odd to me. The error I get is:

           > Running phase: unpackPhase
           > unpacking source archive /nix/store/6a9kaz88xzhw8gd5v3wf3ifzd8ncxgr9-source
           > source root is source
           > Executing cargoSetupPostUnpackHook
           > Finished cargoSetupPostUnpackHook
           > Running phase: patchPhase
           > applying patch /nix/store/lnx0x0q7xl832j6p2klirgnkjqwfzi51-xrizer-fix-aarch64.patch
           > patching file fakexr/src/monado_xdev.rs
           > Hunk #1 FAILED at 3.
           > Hunk #2 FAILED at 111.
           > 2 out of 2 hunks FAILED -- saving rejects to file fakexr/src/monado_xdev.rs.rej
    

    The commit that removes this patch and I believe would fix my issue is 696b10c. Shouldn't commit 353988 include commit 696b10c?

  • source
  • parent
  • context
  • [–] 2 points 5 months ago

    I prefer using the native language usually, but i also don't manage my dotfiles with home manager at all anymore, because i have scripts that need to edit my dotfiles with sed, so if i need to then rerun home manager switch again every time it slows down my scripts a lot. I know there's out-of-store symlinks for that, but that didn't work either cause sed would always error out when trying to follow the symlink chain, so i just gave up on it.

  • source
  • [–] 2 points 5 months ago

    I usually prefer using nix because it has type checking and the syntax highlighting works without having to put it in its own file. (Although larger configs need their own file anyway)

    But I'm not too bothered by having other languages in there.

  • source
  • [–] 5 points 5 months ago*

    No, I don’t configure using nix, but partially because I don’t use home-manager. So I just write in the native config language.

    The other reason is that I don’t believe configuring everything in nix is sustainable. You’re adding another layer that needs to be maintained by someone, and there isn’t much benefit. The native config is as much part of my configuration as a pure nix configuration would be.

    And it doesn’t really matter whether it’s dedicated files or just inline in a nix module. I decide based on complexity. My neovim config is spread out over many files, but all other configs are inline.

  • source
  • [–] 4 points 5 months ago*

    Generally, if there's a NixOS/home-manager module for it I'll use that option. Having everything in one place is more important to me tho than having it in one language so there's a few things that I have the native config lang for. nvf is a godsend tho bc I have tried so many times to configure neovim the "regular" way and it is just incomprehensible for new people (or at least it is for me) who have not been in that ecosystem for the seemingly millions of changes the config/setup process has endured over the years

  • source
  • [–] [S] 2 points 5 months ago* (1 child)

    My goal is to cross-compile from nix to windows. I need to have this program running on windows (or at least provide binaries for it haha), but I really don't want to dual-boot again (I just got rid of windows a couple of months ago, and I'm not too keen on looking at it again in the near future). Maybe I phrased my question the wrong way.

    So I don't need the environment to run on windows, it just needs to be able to compile for windows.

  • source
  • parent
  • context
  • [–] 4 points 5 months ago* (2 children)

    Multiple options:

    Use flake-utils: https://github.com/numtide/flake-utils#example

    Create a helper function: https://ayats.org/blog/no-flake-utils (what I do)

    flake-parts: https://ayats.org/blog/no-flake-utils#option-a-flake-just-for-yourself , https://github.com/hercules-ci/flake-parts

    But this is one of the things I find annoying af about nix flakes. Reproducibility is a spectrum, and I think focusing on "purity" over being able to easily ship it to multiple architectures, or not being able to use the GPU is a step too far on that spectrum for the vast majority of usecases. I can understand why scientific computing or anything that needs absolute precision might want it, but most people only just want the same versions of packages installed in their development environment.

    EDIT: whoops forget everything I said, you are asking for cross compiliation of a dev env to Windows. Nix doesn't support Windows. It only supports linux. You can't make a nix dev shell that works on windows.

  • source
  • [–] 2 points 5 months ago*

    Yeah, NixOS is definitely a journey. For me personally, a very fun one. You’re kinda experiencing what is was like experiencing linux for the first time. Took me like half a year to get proficient with nix in a way I was productive with it.

    That configuring some programs is completely different from how it should be is a weird quirk of home-manager. I personally don’t use it, it adds a lot of complexity for not much benefit.

    But for me, nix saved me in terms of linux. I‘m someone who frequently switches around devices or just completely wipes their existing ones (I‘m very messy with file management, and I just need a clean install after a year or two). It was incredibly annoying to use other distros, especially if you are tinkering a lot it can occasionally happen that you brick your install. You kinda had to document all the fixes for certain issues so that you didn‘t forget them. I could think of more things. That’s just specific to me, but Nix solves all those problems. Not sure I‘d be using linux if it wasn’t for NixOS.

  • source
  • parent
  • context
  • [–] 3 points 5 months ago (1 child)

    not 100% sure but I think the permittedimsecurepackage option takes effect after the rebuild. Doing the first rebuild with the env-override and --impure should work, and then it should work without for the next ones.

  • source
  • view more: ‹ prev next ›