nix-direnv

for the foreseeable future. In my opinion, one may as well take advantage of that. If you haven't already, I'd get your feet wet with installing Nix on a non-NixOS machine first, and please feel free to ask questions about Nix in the NixOS Discourse "Help" section. I have some recommendations: 1. https://github.com/nix-community/nix-direnv - Since Nix derivations usually wrap around other build systems, the entire derivation is recomputed when any file in it changes; using direnv, you can just get your normal dev tools upon cd'ing into your project directories. This gives you a lot of the benefits of Nix during local development, but with your normal stack, and without needing to globally install anything. Importantly, this works around the problem of needing to rebuild your project every time a file changes; Nix caching isn't granular enough (at least when wrapping around other build systems as it normally does.) 2. If you are trying to build something, chances are you can find inspiration in Nixpkgs. Are you curious how you might package a Bevy game? No problem: literally search "bevy" on the Nixpkgs GitHub repo and see what comes up. I found a derivation that does: https://github.com/NixOS/nixpkgs/blob/master/pkgs/games/jump... 3. If you use flakes, you should keep the flake "schema" handy. There are a lot of different kinds of flake outputs and there are different ways to specify the same thing, which is somewhat needlessly confusing; keeping the flake schema handy will make it easier to understand what Nix is looking for in a flake, which might make it easier to see what's going on (especially if it's obfuscated.) The most important takeaway here: A command like `nix run flake#attr` will try multiple different attributes. https://nixos.wiki/wiki/flakes#Flake_schema 4. Likewise, I really recommend reading up on what NixOS modules are. NixOS modules are the basis for configurations on NixOS, and having a clear understanding of what is even going on with them is a good idea. For example, you should understand the difference between the Nix language's `import` directive, and using the NixOS modules `imports` attribute to import other NixOS modules. Understanding how the configuration merge works saves a lot of headache, makes it easier to understand how people's configurations works, and also makes it easier to modularize your own NixOS configurations, too. https://nixos.wiki/wiki/NixOS_modules Unfortunately though, there's just no way to make it "click", and I can't guarantee that it's worth all of the effort. For me, I felt it was, but yes, there's no one correct way to do it. But please feel free to ask questions if anything seems confusing.

lock-file flag I need to pass sometimes. If you put some of your config in default.nix or shell.nix or whatever, you’ll need to watch_file resp. nix_direnv_watch_file those.) [1] https://github.com/nix-community/nix-direnv#direnv-source_ur...

an any other distro I tested before thanks to the isolation that Nix provides. > a question on dev environment isolation. [...] Or is it better to just use their respective package managers on top of regular Linux? I imagine those are part of the same question. Generally what I recommend for newbies is to start small: yeah, it is fine to continue using your respective package manager, specially if you don't need "native compilation" [2]. After you get more experience with Nix though, I would recommend you to start isolating your development environments. Nix has its own `nix-shell`, that it is kinda bare-bones but works well, and can be very practical once you use something like `nix-direnv` (https://github.com/nix-community/nix-direnv/). There is also this `devshell` (https://numtide.github.io/devshell/intro.html) project that is interesting. > Also, anyone here doing desktop #virtualization? Is there a sense of running a #VM per project? Is that a viable alternative to dual-booing Windows when I want to do some Windows dev or play a game? I put those two questions together because yes, I ran desktop virtualization on NixOS, and yes, I ran Windows on a VM to play games thanks to PCI-e passthrough (my dedicated GPU is connected directly to the Windows VM so the performance is near native) [3]. Again, I will not recommend you do to this right after starting NixOS since it is one more thing to possible frustrate you, but just so you know that it works and works well, specially because my VM configuration on NixOS is also on my `/etc/configuration.nix` and it is fully reproducible. Coincidentally I was messing with my VM settings yesterday and "broke" my VM multiple times, however I just run one command and restored it to the previous state. However I never bothered to dual-boot NixOS/Windows, because I barely use Windows nowadays so I find rebooting my system just to use Windows bothersome. Probably not your case, so maybe dual-boot makes more sense. This article should help and seems very easy to do (again, disclaimer, not tested because I never needed it): https://nixos.wiki/wiki/Dual_Booting_NixOS_and_Windows. About the VM per project, unless you want to do this for some other reason (security maybe?), you don't need to. As I said before, you can use things like `nix-shell` and this will already give isolation enough for development purposes. --- Some closing words: remember, start small! Nix/NixOS is a journey. You will learn eventually what you need. However, if you try too many things at the same time you will feel frustrated. The official documentation is good, however it kinda assumes that you know what we are talking about already, and it is also very big and not well separated in steps, so it feels overwhelming for newbies. To supplant this there are many blog posts, however some of them are out-of-date (it shouldn't be too much of an issue though, since Nix tries really hard to backwards compatible). You will eventually need to learn the minimum of the language to read the source code. It is less difficult than it seems, because while Nix as a language is strange at the first glance, it is a very well designed DSL for the domain. After sometime editing your own configuration you will naturally learn the Nix language, and can start to understand what is happening. For where to start, I recommend trying to replicate your current system in a NixOS install. If you already use another Linux distro try to get the same desktop environment and packages that you already use. If you're coming from Windows/macOS try Gnome or KDE. Just tweak the system until you're happy with the result. Eventually try Home-Manager to manage your Home configuration in the same way as in NixOS (fully declarative), and once you feel happy, you can try Flakes (making you configuration fully reproducible). This process can takes months or even years, but don't bother or rush, just continue your journey. It really pays off in the long run. [1]: well, I am on a "coding spree" right now so I am doing many changes, most to refactor some things that I wasn't happy before; but before this coding spree my configuration didn't change significantly for almost a year. [2]: what I call having to compile C/C++ libraries in an another language like Python (giving it an example here, almost any language has a similar mechanism since C/C++ ecosystem is huge), that generally needs to dynamically link with whatever you have in your system installed. This is possible on Nix/NixOS, and easy once you know what you're doing, but it is different from anything else so it does trip newbies. [3]: if you're interested on this approach, I used this guide when started: https://forum.level1techs.com/t/nixos-vfio-pcie-passthrough/.... To get it fully reproducible it though, there is no way on NixOS itself yet, however there is a good guide here: https://nixos.wiki/wiki/NixOps/Virtualization#Setting_Up_the...