Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We want to make Nix better

determinate.systems

Post reply on HN
Print view View original

41–50 of 204 posts

Re: We want to make Nix better

#41

Post by microtonal »

tadfisher wrote: post #23
ridiculous_fish wrote: post #4

I installed nix on my Mac but quickly backed out due to the complexity. I assumed the nix store would just be an ordinary directory with a tool for managing it, similar to brew. I discovered it creates a new Unix group, adds a separate APFS volume, installs a daemon. This was too invasive for a tool I was unsure if I even wanted to use, so I uninstalled it. What is the reason for all this machinery? I went with the r…

> What is the reason for all this machinery? > new Unix group This is used for the daemon, so it doesn't run as root and expose your system to Nix build code. > adds a separate APFS volume I think this is required because of macOS security restrictions preventing direct modification of the root directory. The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute p…

The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix,

This is true, but in some sense Nix on Apple Silicon was a missed opportunity. It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. This would have solved the whole dance needed with volumes and synthetic.conf. I know that there are infrastructure issues (like Hydra using a single Nix store), but it would've made the macOS Nix story so much better.

It's a shame that only Apple can make firmlinks, because that would've been another possible solution (/nix could be a firmlink to the actual store location).

The same problem occurs on e.g. Fedora SilverBlue, because you can also not make arbitrary root directories. But at least on Linux, you don't want to throw away more than one decade of a x86_64 binary cache.

Re: We want to make Nix better

#42

Post by rgoulter »

chrisseaton wrote: post #34
rgoulter wrote: post #32

Earlier quoted context omitted.

One of Nix's benefits is it aims to isolate where programs are installed; so you can have multiple versions of the same program available without conflict. (e.g. programs built with different feature flags, or multiple minor versions). Nix achieves this by storing packages in a path as some hash of its inputs. -- This then allows either compiling or downloading a package, with confidence that it will behave the same…

I guess I don't understand what you meant by 'The compromise was putting /nix on a separate directory' then?

Oops. Wrong word. I meant "separate volume".

/nix could still be used if it's on a separate volume. Which still seems less nice than just having /nix on the same volume.

Re: We want to make Nix better

#43

Post by yewenjie »

zuzuleinen wrote: post #26

"But there’s a catch: to make that happen you need to write some Nix, use Nix tools, and probably consult several documentation sources." You can use bob[1] if you want a build tool which uses Nix to install dependencies in an easy manner: just list the package names for a task and then they will be installed. I'm looking forward for all the changes in Nix ecosystem and it's a good sign the fact that they also starte…

How does Bob handle network requirements (downloading dependencies during the build)? I think that is one of the biggest pain points for nix packaing. Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.

Re: We want to make Nix better

#44

Post by setheron »

grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

I wish this blog post had more meat to it. It was pretty minimal on information.

This is also due to the fact that I tend to value Graham's posts highly :)

Re: We want to make Nix better

#45

Post by microtonal »

rgoulter wrote: post #32
chrisseaton wrote: post #20

Earlier quoted context omitted.

Right but the comment said they compromised on using a different directory in the end, so it could be under /opt like Homebrew, and not a root directory.

One of Nix's benefits is it aims to isolate where programs are installed; so you can have multiple versions of the same program available without conflict. (e.g. programs built with different feature flags, or multiple minor versions). Nix achieves this by storing packages in a path as some hash of its inputs. -- This then allows either compiling or downloading a package, with confidence that it will behave the same…

But, since the files were under /nix, if you put them under /opt, then you wouldn't be able to make use of the compilation caches for /nix.

Until a very short time ago there was no binary cache for Apple Silicon Macs.

Re: We want to make Nix better

#46

Post by biggestlou »

setheron wrote: post #44
grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

I wish this blog post had more meat to it. It was pretty minimal on information. This is also due to the fact that I tend to value Graham's posts highly :)

Consider this post more of a "hello world." Substance is on the way :)

Re: We want to make Nix better

#47

Post by setheron »

Funny enough I introduced Nix to our company which was acquired by Google -- so Google has software leveraging Nix. (I got Google to in fact sponsor Nix which was nice too. A small amount but it was meaningful to me).

Re: We want to make Nix better

#48

Post by rgoulter »

rrgok wrote: post #33
rgoulter wrote: post #28

Earlier quoted context omitted.

> 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. It's the same as homebrew: If there's a cached binary already, it will download the cached binary. If not, it will fetch the source and build it. The QMK nix shell needs different GCCs for different targets. For the QMK shell.nix specifically, you can disable the targets you don't need (e.g. if you don't use a teensy b…

That makes sense. Is there a `nix-shell` option that outputs which packages will be compiled from source and which will get a precompiled binary? Something like `nix-shell --dry-run`? I have to learn more about the nix language, but looking at the shell.nix seems that I have comment/remove lines from 25 to 30 according to my board.

The easiest is to change the default:

  { avr ? true, arm ? true, teensy ? true }:
Change `true` to `false` as needed, only keep the ones you need for you keyboard(s).

Re: We want to make Nix better

#49

Post by kaba0 »

qudat wrote: post #9
edolstra wrote: post #5

Earlier quoted context omitted.

It's because Nix wants to install into /nix. Once upon a time doing "sudo mkdir /nix" wasn't a problem, but recent macOS releases have made that very hard. Nix could switch to an alternate location on macOS (e.g. /opt/nix) but that has a lot of downsides for interoperability with other systems.

Yikes, I had no idea. What a tough pill to swallow all because the directory nix runs out of is hardcoded.

It’s not actually hardcoded, but you would have to compile everything from scratch as the hash would depend on that as well, throwing out the whole binary cache.

Re: We want to make Nix better

#50

Post by grhmc »

tadfisher wrote: post #31
grhmc wrote: post #2

With Eelco as a cofounder of DetSys, I feel really excited about where we're going here. I think the world is in many ways primed and ready for Nix, as long as we can help Nix "meet them in the middle." We're working on making Nix more accessible and producing good and usable, production-ready workflows so teams can just pick it up and go. I'd love to hear what y'all think, to help make sure we're going in the right…

I might suggest making a typed superset of Nix, basically adding record types and function signatures. That in itself would be a huge boon for tooling and interacting with nixpkgs. nixpkgs describes a huge and varied meta-API for derivations in various build ecosystems, which makes it hard to use because you ultimately need to dive into source code.

We've heard this feedback pretty frequently. We have a few ideas of ways to add some types to Nix in place. I think even simple naive approaches would add a lot of safety and improve the usability of Nix.

However, one of the bigger problems here is the general API design of Nixpkgs. Most of the function interfaces use some named parameters and then use `...` to accept any additional parameters. All of those then get passed down to some other function, and on and on. This makes a mess! It is hard to tell what functions use what parameters, and none of them can restrict their interface.

We could see some significant DX here by creating smaller, more specific interfaces that actually restrict their inputs.

Post reply on HN