Yeah, you're right. I completely misread that and I've been barking up the wrong tree. I guess that makes this a nixpkgs-xr conversation rather than a flakes one. Thanks for pointing that out.

It looks to me like 696b10c removes the filter that previously skipped the xrizer-fix-aarch64 patch. So I would expect that patch to be applied in the latest nixpkgs-xr

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?

Also using something like that takes all the fun out of configuring it yourself.

Last commit is 353988 and your flake.lock lists 353988... looks like it's doing what it should?

Can you double-check? Did I misunderstand?

My flake.lock is unchanged after running that command. https://pastebin.com/zbLKg742

What does your flake.lock look like before and after running nix flake update nixpkgs-xr ?

Well TBF if you got the ram (and storage), may as well go big lol

I limit mine to 4gb because I got 2T to go through and I got 32 gb of ram sitting there

Did you scroll sideways in that table?

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.

A very interesting tool so thank you for posting this.

The docs are very impressive and detailed which is nice.

How did you arrive at 8GB hash table size?
I've tried understanding the example table in the docs but it doesn't make any sense to me.

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.

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.

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

Ah, I see.

A quick search leads me here: https://discourse.nixos.org/t/nix-on-windows/1113/105

which you might have seen before. It is a very long post, but some people mention having achieved what you want.

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.

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.

I'm not using flakes yet but the intent-to-add git option is new to me and seems very useful, thanks!

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.

Every time k read about the problems flakes have, I realise how experimental they are.

i think imma go with that, tho i'd prefer if i could have my config stay pure i'll have to troubleshoot more

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.

yea I'm in fact evalutating a flake, u can find it here, but I usually override my inputs' nixpkgs input with mine. I'm using nh to rebuild my config, running nh os switch -H nixos

Yea I'm pretty sure I've also did this correctly since it in fact worked just fine with this electron package I've had in here for a little while now. Looking in nix-tree and searching for nodejs but the only nodejs versions I'm finding are 24.14.1 and no sign of the insecure version. Tried exporting the env and rebuilding my config but it didn't work either

Several things come to mind. First, I think that you followed the instructions correctly; it doesn't look like you did anything wrong, and I'm guessing that this previously worked for Electron. Second, I would consider hunting down the insecure packages and fixing them; my main tool for this would be nix-tree. Try nix run nixpkgs#nix-tree, using the '/' key to find "nodejs" packages. Third, if you have one insecure network-facing package than you might as well consider marking the entire system as temporarily insecure and exporting NIXPKGS_ALLOW_INSECURE to the environment; this is overkill but it will tell you whether there are other extistential issues with your configuration.