I still fail to understand the naming conventions behind Nix. I don't know what a "flake" or "derivation" is without double checking, the naming sucks.
NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
71–80 of 186 posts
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#72Earlier quoted context omitted.
It depends on what you're hoping to get out of it. I mostly-whole-ass it, but I still use the mac app store and homebrew for a few things. Most projects are Nix by this point. It's hard to tell from how you say it; if you aren't using it for any projects and would just be using it for a slice of your system/user packages, I suspect you'll end up not really seeing what the fuss is about. If you will try to use it with…
How do you personally use Nix on a project, any tips? Do you use flakes? What are first steps/basic scaffolding? I am eager to get into Nix but not ready to go full on (I'm also on Mac but some devs may be on Linux) Is it possible with complex projects like based on Electron? Is it reasonable to use Nix in Docker (eg. I am on Mac but want to build it like it's on CI)?
> How do you use Nix on a project, any tips?
Combining nix with direnv is a popular combo for dev environments. Example: https://determinate.systems/posts/nix-direnv
If you haven't worked with nix before, the quick start here is a good place to start https://zero-to-nix.com/
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#73One smaller UI improvement I would like to see is being able to retrieve the exact git commit of an installed flake. This seems not to be possible atm. Main argument for not having this is putting a reference to the git commit into the nix store folder would break hermetic evaluation. (You can habe multiple commits resulting in the same code.) It should however not be too hard to log that information separately somewhere else. It is somewhat disapointing for this link to be missing when flakes are already tied to git as they are.
The log entries could also include a flag if the flake was installed "dirty" (having uncomitted changes at the time).
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#74The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…
> Building third party flakes takes forever since every flake uses its own version of nixpkgs.
That's not quite right. It may use a predefined version of nixpkgs and there may be a reason the version is hardcoded to something. But if that's not what you want, you can use something like `nix run ... --override-input nixpkgs nixpkgs` and it will run with your current system nixpkgs version instead.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#75NixOS is honestly so beautiful and rare. I'm delighted that the project is moving forward in this way. A friend of mine called it a "rabbit hole" but TBH it's words of power -- I can speak new instances of my environment into existence, not only on newly-acquired compute devices, but on other OSes as well (I put some effort into segmenting the user environment and system config between home-manager and standard /etc/…
> I can speak new instances of my environment into existence
You're not kidding. I used nixos-anywhere [1] for the first time the other day. You can point it to any linux host and it will partition, format, and supplant the target's existing OS with your nixOS config, all with a single command. Incredible.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#76Earlier quoted context omitted.
I think we all have our own aha moments with things like this. I thought like you until I really dug in and set up Home Manager as well. My moment, and maybe this means nothing to you, was when I realized I could reference any package in a config file without even “installing” it. So it’s no longer that I have config files in Git somewhere, and then also a list of all the packages I need to install somewhere else; th…
I'm familiar with home manager (or as I like to call it, a hammer looking for a nail, that solves no problem). I don't think home manager has any relationship with flakes. Also, nix solves actual real problems, home manager doesn't. There are better dotfile managers. In fact, vim understands the syntaxes of a lot of dotfiles, with home manager, you even lose that.
There are Nix LSP servers now that handle embedded config files. But beyond that, you can always just leave the config in its original format and import it into the Nix config, and not lose your syntax highlighting.
Speaking of vim, I've got neovim configured completely with home manager. It references plugins as first-class nix packages, and also any external dependencies like language servers, node packages, parsing tools etc are also managed by Nix. You can reference the deps in the vim config and it will automatically download and point to them in the nix store without even installing them.
It's amazing. Everytime I upgrade and building my system, my nvim setup gets upgraded automatically too. No need for a package manager or manual updates.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#77My biggest problem with flakes is that it is too much added complexity for tiny incremental gains (as per my limited understanding, happy to be corrected). Not only do most users gain very, very little from it, it also deters users from using nix for two reasons: 1) There is more to learn now. 2) Split ecosystem. I'm looking to be educated, I've made contributions to nixpkgs (two "mid-sized" changes) but for some rea…
> Not only do most users gain very, very little from it How do you come to that conclusion? Those who switch to using flakes are enthusiastic about the improved UX. > flakes is that it is too much added complexity for tiny incremental gains A 'flake' is more/less a set of inputs and a set of outputs. I'd say it's less complicated than a package.json file in an NPM project. The benefits are hard to get otherwise. With…
For me the biggest benefits of flakes are:
- flake-specific state is fully captured and locked
- this locking applies for all platforms the flake targets
- extreme ability to be composed
The first two solve the same issue as Gemfile.lock, its the PLATFORMS section, and the platform annotations on each of its gem line, which allows `bundle lock` to lock not just for the platform it's being run on but all platforms that are targeted.
It also canonicalizes the way to declare targets to build, whereas previously it was kind of TIMTOWTDI (e.g default.nix evaluation is the default target and calling nix-build sans arguments builds that to `result`, and if you want more you write alternative nix files, the whole organisation of that is on you)
These are very useful for project-oriented nix stuff.
For system (nixos, nix-darwin)/environment/profile/home management I still prefer classic channels, which gives me a single, consistent nixpkgs source, kind of like BSD's base which is handled as a whole (except here it applies to the whole of packages). I am still able to locally override this or that by selectively pulling another nixpkgs (or other source) and use that to pick a specific package version (either forward or backward) but otherwise I stick to the single consistent one.
It feels to me that using flakes for the whole system would be like using npm and having a whole recursive tree of `node_modules`. I certainly don't want to have a thousand different openssl around!
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#78Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…
It can get you two major things. Docker-like reproducibility for any development project in a much more convenient way. And the ability to try lots of software without installing it. For me, the last one is a gamechanger, as I am no longer worried about littering my system with tons of dependencies. Say I want to convert an eBook I downloaded. I can quickly use Calibre for a one-off thing, with nix run nixpkgs#calibr…
I also really like flakes. I know they are still experimental today - though hopefully that'll improve with this RFC - but they make it trivial to have an out of tree package. For example I just recently created a flake for a vendor OpenOCD fork [0] - and now I can reference that in my home-manager config or from some other project.
[0] - https://github.com/benpye/openocd/blob/mrs-2023-08-07/defaul...
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#79The biggest show-stoppers for me with flakes is: Building third party flakes takes forever since every flake uses its own version of nixpkgs. If you don't pin your third party flake urls they might also change under your nose as you run the same command again a day later. Flakes are coupled to git. You need to remember to stage changes whenever you do Ctrl+S in your editor before rebuilding. I've wasted more time tha…
I used to be annoyed by how Flakes are coupled to Git, but I've realized that dealing with that is way less pain than dealing with builds that accidentally depend on non-version-controlled files. Missing an unstaged file is annoying, but it gives you an explicit error message and it's easy to fix; accidentally depending on a wrong file can skate by silently (perhaps leading to extra rebuilds but nothing more) until you try to reproduce the build somewhere else, and then it's at least a small headache to debug and fix.
Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally
#80Ive always loved the idea of nix, but feel like I've read numerous, if not horror, at least uncomfortable stories about the actual real-world experience after the initial "setup yak shaving" is done - which is often exciting for "us", it's the new project problem solving part before it falls into the boring "work" part. If I have an arch system now, how useful is it to use Nix or Homemanager on a non-nixos linux syst…
It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit. Fully reproducible environments with home manager and nixos are neat but IMHO you can just use ansible to do the same thing on debian, arch, etc. if those systems have…
> It's fine, just be sure you know where your tools are coming from (use the which command a lot when unsure). Nix might have more up to date or bleeding edge software, although since you're on arch in my experience nix can lag even arch by a little bit.
That'll depend if you're on stable or not. If you're on stable and you need something from unstable that's also possible without any real risk of breakage on NixOS.