Live data from Hacker News

NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

github.com

91–100 of 186 posts

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#91
post #81

Ive 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…

I'm running home-manager on arch and it's fantastic. I'm only using it for cli/tui programs, as I've had trouble getting gui software to correctly create desktop entries which show up in my menus. You can use it alongside pacman just fine.

In the worst case scenario, you can just manually create files in your home directory if needed, so putting them under .local/share something should get you desktop entries (though depending on the desktop/window manager you may need a restart).

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#92
post #20

Earlier 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? 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)

Not sure I can boil it down to tips, but: more or less any time I need to do something regularly that involves third-party code, I'll be using Nix to manage it. Specifics depends on the project. There are templates around (and templating is built into flakes via `nix flake init`), but I haven't used those much myself.

Maybe a sense of general patterns helps?

Most of my projects have at least a shell.nix (devShell expression in flake.nix) for setting up an environment to work on the project. I.e., add appropriate deps to path, define some utility shell functions, start up database servers and so on.

Sometimes that's all. For example, my blog just has a shell.nix for providing dependencies like hugo, gist, make, jq, etc., defining some helper functions for scaffolding new posts and such, and then I use Makefile targets for creating a dev build, production build, and publishing.

If it's something others might use, I'll generally have a default.nix/flake expression for building the package. Then I can use that for testing it, for integrating it in other projects or my own systems or whatever.

I'll often have one or more expressions for ~testing it. (If I have more than one, the first might be a straight test, and the 2nd might be a performance suite comparing it against similar tools, for example.)

If I'm researching several potential alternatives, I may build a Nix expression that builds all of them, pulls them all into scope, and then invokes them all to compare whatever I care about. Then I can readily repeat the same check locally, or go run it a bunch in CI.

If it's something I have CI set up for, I may bother to have a ~normal build that runs against pinned dependency versions whenever I make code changes, and then also set up a ~canary build that regularly re-runs my project's main/master against the latest nixpkgs so that I get some notice if something I depend on happens to be broken.

> Is it possible with complex projects like based on Electron?

I'm not familiar with the Electron packaging, sorry. I know it's doable because we've got a number of electron packages, but I don't have perspective on how easy it is and whether it's working on Linux and macOS or just the former.

> Is it reasonable to use Nix in Docker (eg. I am on Mac but want to build it like it's on CI)?

Sure. There's an official Nix container image, and some of our gitlab CI jobs use it. IIRC it's a little tricky to install Nix in a container imperatively, but I think the state of that has improved since the last time I needed to fiddle with our setup.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#93

Earlier quoted context omitted.

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…

> When you inevitably find software that isn't in nix (or are packaging your own software), be prepared to take a quantum leap in complexity as you now need to fully understand the nix language and its concepts like derivations. This isn't necessarily hard but it is not documented well at all, and there are factions in nix at odds with each other (flakes vs. nix-env) which make learning it even more confusing. Exactl…

In 90% of the cases it is as easy as modifying the earlier version’s version and hash. I think learning nix from outside-in is perhaps easier - grep for something you are looking for, and as if it were a language and you are a small kid, imitate that.

Though I will give you that there is enough complexity in specifying which nixpkgs/flake gets built, where is it places, etc as is, especially with the `nix-\w+` vs `nix \w+` variants being slightly different, to the point that I always have to look it up in the man page/in my history whether I need -A and the like.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#94
post #61

Earlier quoted context omitted.

It's no lighter than a process running in docker, on a Linux machine at least. With docker you have a whole root filesystem packaged up and a process inside it is executed on your system with certain kernel namespacing to set its root filesystem, users, network access, limits on memory and CPU usage, etc. With nix instead of a tarball being the root filesystem it's a bunch of symlinks to stuff in the nix store direct…

It’s a lot lighter in terms of disk space. Yes, drives are cheap, but even so, bringing in a different version of debian-slim for every executable gets bloaty. I routinely reclaim 10s (sometimes 100s) of gigs with a podman system reset.

Also in RAM. You don’t want to runa whole-ass container for `ls`.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#95
post #92

Earlier quoted context omitted.

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? 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) Not sure I can boil it down to tips, but: more or less any time I need to do something regularly that involves third-party code, I'll be using Nix to manage it. Specifics depends on the project. There are templates around (and templ…

Thanks, this is super helpful!

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#96

My 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…

As a counter-anecdote, as someone who used to be a newcomer to Nix, it took until I encountered flakes before I went "aha, this is how it was always meant to be".

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#97
post #91
post #81

Earlier quoted context omitted.

I'm running home-manager on arch and it's fantastic. I'm only using it for cli/tui programs, as I've had trouble getting gui software to correctly create desktop entries which show up in my menus. You can use it alongside pacman just fine.

In the worst case scenario, you can just manually create files in your home directory if needed, so putting them under .local/share something should get you desktop entries (though depending on the desktop/window manager you may need a restart).

Yeah, I'd much rather just install with pacman than manage them manually though.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#98
post #6
post #4

> With the goal of ending this current limbo and soothe longstanding tensions in the Nix community Can someone with more background give a quick explanation about why is this a source of tension in the nix community in the first place? Is this a situation of too many cooks in the kitchen or something else?

Because Flakes are simultaneously discouraged and labeled as unfinished, yet used by many. Some aspects of Flakes are a bit contentious. For example, official adoption of Flakes will mean Nix will no longer be a mono-repository. Plus, Flakes are tightly coupled to Git. However, Flakes bring welcome improvements to longstanding issues. Most notably, package pinning and explicit versioning, which are problematic when u…

> For example, official adoption of Flakes will mean Nix will no longer be a mono-repo.

Do you mean nixpkgs? I don't think stabilizing flakes means nixpkgs won't remain a monorepo.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#99
post #71

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.

> without double checking

It's fine, Nix things are conceptually different from anything before.

You could say flakes are like Rakefile, but that would be a lie. You could say they're like Gemfile and Gemfile.lock, but that would be a lie too.

You could say that derivations are like packages, but that would be a lie, you could say they're like container images but that would be a lie too.

Now, you can try to understand what these concepts are by mapping to known knowledge of other things in terms of use cases they solve, that's fine, but at their core these concepts are different and quite unique, so it only makes sense for them to have different names.

Naming is hard, Nix folks had to pick one for each concept, and they chose not to lie by picking existing names that would not map and create bias in the understanding and expectations. It makes for a steeper learning curve, but I'd argue long term in the learning process it's the right move.

Let me try to give some synthesised definitions (which may be incomplete and lies in the Feynman sense):

- a derivation is the reification (or realisation, as in, "make it real") of a function call on the filesystem. IOW the concrete result is derived from the function call, memoized using content addressing.

- a flake is a central definition of a number of target derivations in the context of a specific source state of dependencies. If you look at an actual (snow)flake there's this recursive/fractal design coming from a central point, which kind of visually represent the conceptual structure underpinning a nix flake.

So for me the names totally make sense! But I can understand that they don't out of the blue (and they did not for me at first!)

It turns out (not really by accident) that these cover use cases that were implemented by this or that tool, and instinctively through a partial understanding of the nix concepts we're in conflict: the other tools give us a (biased) understanding which both increases and is in conflict with our understanding of nix concepts. This is a normal process, but at some point by letting go of what we previously know and trying to understand new things for what they are and not what we project onto them, we open ourselves to fully grok, and both fully leverage the new concepts and realise their limitations.

Re: NixOS RFC 136 approved: A plan to stabilize the new CLI and Flakes incrementally

#100

The 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…

Well, not necessarily. There’s a `follows` argument to pin through the different dependencies. It’s not ideal but it’s there.
Post reply on HN