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

51–60 of 204 posts

Re: We want to make Nix better

#51

Post by mixedCase »

Hot take as a NixOS user that uses Nix for work: "all" we need is a much better, sound, statically typed language to build better abstractions with.

The only hard requirements I can think of are algebraic data types with exhaustive pattern matching to go with, row polymorphism, purity and good inline documentation support.

I don't know if a good enough hostable language exists or if it should be a new version of Nixlang, but almost every single annoying problem that makes me go "Nix is getting in my way" can be traced back to the lack of a good, powerful type system leading to a house of cards situation whether it comes from nixpkgs or entirely of my own making.

Re: We want to make Nix better

#52

Post by wmertens »

microtonal wrote: post #41
tadfisher wrote: post #23

Earlier quoted context omitted.

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

Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing.

Although it is my hope that rfc 17 eventually makes it through: https://github.com/wmertens/rfcs/blob/master/rfcs/0017-inten...

Re: We want to make Nix better

#53

Post by rgoulter »

ParetoOptimal wrote: post #29
grhmc wrote: post #22

Earlier quoted context omitted.

Single-user Nix installs are lighter weight, but also have a major compromise: the store is writable by the user. This means it is pretty easy for software you're using to accidentally change the store underneath Nix, and create unpredictable and unreproducible behavior. I think the multi-user install is a better Nix experience, even if the install process is spookier. Like is mentioned elsewhere, Docker does similar…

> I wonder if it would have been more palatable if the Nix installer was less forward about what it is doing? I bet most wouldn't consider it spooky if the installer didn't print it out. If docker started printing it, I bet lots of people would complain it seems similarly complex.

I recall the sqlite changed their tmpfiles on Windows from "sqlite" to "etilqs".

Re: We want to make Nix better

#54

Post by rrgok »

rgoulter wrote: post #48
rrgok wrote: post #33

Earlier quoted context omitted.

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).

Thank you, I will try again with your suggestions!

Re: We want to make Nix better

#55

Post by rrgok »

ParetoOptimal wrote: post #40
rrgok wrote: post #33

Earlier quoted context omitted.

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.

> Something like `nix-shell --dry-run`? Exactly that? Lol :)

Really? It is not written in the official nix-shell manual

https://nixos.org/manual/nix/stable/command-ref/nix-shell.ht...

I still will try when I get to my macbook. Thank you!

Re: We want to make Nix better

#56

Post by wmertens »

kaba0 wrote: post #49
qudat wrote: post #9

Earlier quoted context omitted.

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.

Actually, there's quite a few hard-coded references to /nix in nixpkgs I believe. It's possible but a little more work than just changing the prefix.

Re: We want to make Nix better

#57

Post by Arcuru »

Since Eelco (often treated as Nix's BDFL) and Graham (also very prominent in the Nix community) are involved hopefully this group will actually be able to make traction on some of these issues. This is not even close to the first of these posts saying "we're going to help make Nix more user friendly!", but maybe this group has a chance of making changes to the Nix ecosystem since they can just approve it themselves.

I've had concerns about Nix's governance in the past but it sounds like they may be going in the right direction, so I'm excited to see what they're planning.

Re: We want to make Nix better

#58

Post by tadfisher »

microtonal wrote: post #41
tadfisher wrote: post #23

Earlier quoted context omitted.

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

> 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.

That breaks caching cross-compiled outputs and x86_64 outputs, which do still run on Apple Silicon.

Re: We want to make Nix better

#59

Post by microtonal »

wmertens wrote: post #52
microtonal wrote: post #41

Earlier quoted context omitted.

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…

Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing. Although it is my hope that rfc 17 eventually makes it through: https://github.com/wmertens/rfcs/blob/master/rfcs/0017-inten...

Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing.

Sure. But it's still nice that e.g. on Linux x86_64 you can use a nixpkgs commit from 2015 and get all stuff from the binary cache.

Re: We want to make Nix better

#60

Post by zuzuleinen »

yewenjie wrote: post #43
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.

I wrote a short guide[1] how bob uses Nix, but essentially we still use `nix-build` under the hood to build a list of packages you give under dependencies

> Many projects have build instructions that depend on downloading stuff in a complex manner that cannot be easily abstracted/shaped to what Nix expects.

Are you referring here to packages which are not available in Nixpkgs?

[1] https://bob.build/docs/usage/package-management

Post reply on HN