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

31–40 of 204 posts

Re: We want to make Nix better

#31

Post by tadfisher »

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.

Re: We want to make Nix better

#32

Post by rgoulter »

chrisseaton wrote: post #20
ParetoOptimal wrote: post #17

Earlier quoted context omitted.

OSX requires mounting root folders like /nix with synthetic.conf IIRC.

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

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.

Re: We want to make Nix better

#33

Post by rrgok »

rgoulter wrote: post #28
rrgok wrote: post #18

Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed N…

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

Re: We want to make Nix better

#34

Post by chrisseaton »

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…

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

Re: We want to make Nix better

#35

Post by techdragon »

Jeaye wrote: post #15

Writing the packaging expressions should not be harder than writing the program, for the average developer. The average developer doesn't know FP, at this point. Nix needs: 1. Approachability for those not indoctrinated in lazy, declarative, functional programming (i.e. Haskell); nope, Nix Pills are not sufficient for the average dev 2. Editor tooling to help guide the writing of expressions (just as anyone learning…

Point 4 is what lost me when I tried using NixOS for a machine I explicitly wanted as reproducible as possible. I needed to get a bunch of stuff working, then freeze/bundle/lock the useland as a documented working state I could rebuild later if anything went wrong.

When documented examples began steering me towards the still experimental nix flakes and using the sorts of with ever more flags required commands, I bailed and built it using salt. I want to like nix but the current state of things was a massive put off.

Re: We want to make Nix better

#36

Post by Macha »

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.

This is inherent to having binary packages. Binaries compiled to look for libraries in one location cannot just be copied to a system with a different layout. Nix also can't just use the OS conventions, since part of the point of Nix is that it does not use the global system state and only its own isolated, reproducible world. So then they had to make a decision and decided to just use /nix everywhere which worked fine for some years. And now MacOS has changed, choosing something else would invalidate all historical binary packages.

Re: We want to make Nix better

#37

Post by yewenjie »

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.

https://github.com/tweag/nickel

Re: We want to make Nix better

#38

Post by ParetoOptimal »

rrgok wrote: post #18

Beside being invasive on MacOS, as said by @ridiculous_fish, it took me more than 3 hours (and it didn't yet finish, I just quit all) to use QMK. I just cloned the Github repository of QMK and did `nix-shell` as they provide shell.nix file. 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me. 2. What is the right approach? This is not to bash Nixpkgs, because I installed N…

> 1. Does every nix-shell require building the whole world from ground-up? Seems impractical to me.

Agreed! Most repos with a shell.nix and heavy dependencies use their own binary cache with the service cachix.org (free for public repos).

> But, on MacOS, nixpkgs was not a pleasant experience at all.

Were there reasons besides the QMK nix shell building the world?

Re: We want to make Nix better

#39

Post by zuzuleinen »

biggestlou wrote: post #30
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…

Bob is very cool and I think that there's room for lots of tools like this that build _on_ Nix but abstract away some of the trickier parts. Suggestion: make Bob installable with Nix!

Thanks for the suggestion! It makes sense to have it on Nixpkgs collection since anyway you need to install Nix alongside bob

Already created an issue :)

https://github.com/benchkram/bob/issues/193

Re: We want to make Nix better

#40

Post by ParetoOptimal »

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.

> Something like `nix-shell --dry-run`?

Exactly that? Lol :)

Post reply on HN