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

71–80 of 204 posts

Re: We want to make Nix better

#71

Post by ParetoOptimal »

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.

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

The basic way to fix this with nix is:

1) download the thing with a fixed ouput derivation: a derivation who's source has the URL and checksum of the artifact

2) copy the artifact from the nix store where said build tool stores it

Re: We want to make Nix better

#72

Post by Cloudef »

chrisseaton wrote: post #10
rgoulter wrote: post #8

Earlier quoted context omitted.

> What is the reason for all this machinery? Nix wants to use /nix, but Apple wants macOS to be locked down and secure. The compromise was putting /nix on a separate volume. > I discovered it creates a new Unix group, ... installs a daemon This is at about the same level as Docker, fwiw.

> The compromise was putting /nix on a separate directory. Why does a separate directory need a whole other volume? These are just files, right? Why do they need to be on a separate volume?

Many binaries when compiled gets hardcoded paths compiled into them which are determined during configuration time. This means you cant use binary from a cache if the file hierarchy isnt identical. On linux this isnt a problem due to namespaces (feature originating from plan9).

Re: We want to make Nix better

#73

Post by bpye »

nbp wrote: post #19
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…

My thinking is that this is long overdue! I am working on a very large project where multiple solutions have been invented to solve problem which are all handled by Nix: - Bake in the repository the clone of the dependencies. - Compile the tool chain to create reproducible builds. - Create "artifact" builds, to avoid large recompilation times for many developers. - Use various tools to cache and distribute builds. -…

There was some work being done to make Nix work on Windows [0] - but it might have fizzled out. I too would really love Nix to work on Windows. I already use it on both macOS and Linux and it’s great.

[0] - https://github.com/nix-windows/nix

Re: We want to make Nix better

#74

Post by ParetoOptimal »

skybrian wrote: post #62

The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary. For example, esbuild is written in Go, which is compiled to a different binary for each system. The NPM for esbuild has 21 optional dependencies, one for each binary that it makes available. A post-install script [1] chooses which dependency to install. It…

> The external dependency problem is somewhat solved in npm (at least, as far as many users are concerned) by writing a module that downloads the appropriate binary.

This complicates working on node projects with nix in my experience.

Is there a way to tell npm "no, just use my binary"?

Best i've found is letting npm download it and then overwriting the npm binary with the nix one in a postinstall script.

Why you ask? Npm doesn't always have an aarch64 or arm32 binary.

Nix being a source based package manager typically does support it or at least makes it possible by overriding build/configure options.

Re: We want to make Nix better

#75

Post by ParetoOptimal »

rrgok wrote: post #55
ParetoOptimal wrote: post #40

Earlier quoted context omitted.

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

I misread that as `nix-build --dry-run`, sorry!

You can use nix-build on a shell.nix though i'm pretty sure.

Re: We want to make Nix better

#76

Post by ghoward »

ParetoOptimal wrote: post #68
gavinhoward wrote: post #66

Disclaimer: I'm working on a build system that will eventually do what Nix does but make it much easier to use. If they do manage to create a system where Nix is hidden, and end users never have to directly touch it, I think this could work and make my work never see the light of day. But I have my doubts that they will be able to do that, and it boils down to one simple reason: declarative is not powerful enough. Do…

> However, when more power is necessary, it is required; it is not possible, by the definition of Turing-completeness and declarative, to do the same thing with a declarative language that can be done with a Turing-complete language. So when that power is missing, the only option is to work around it. I fall heavily into the use less powerful languages and "liberties constrain, constraints liberate" camps. I'd be ver…

> I fall heavily into the use less powerful languages "liberties constrain, constraints liberate" camp.

For what it's worth, so do I. That's why my build system will allow users to set those constraints. It's a great idea.

> I'd be very interested in a real world example of this, though I know that class of examples is hard to come by.

There are many, but I'll say one: anything that requires iteration until a fixed point is reached. A concrete example of this is building documentation in LaTeX.

Or it may even be simpler than that. Maybe your build requires some sort of special code should two arguments have specific values. In other words, edge cases often require Turing-compete power to resolve.

Re: We want to make Nix better

#77

Post by hamandcheese »

tazjin wrote: post #63
tadfisher wrote: post #31

Earlier quoted context omitted.

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.

Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact,…

> If you pick a single file from nixpkgs without context, you can't get much information from it at all (other than a lot of unknown types being passed to things that accept an unknown type) - it's only in the context of an evaluation of a graph node that uses that file that you can infer anything meaningful about it (and even then that information is only relevant in that context).

This is exactly where types would be the most beneficial, and what makes nix so hard to read. If a nix function could specify the types of its arguments, then I might have a chance of better understanding it.

Just because most nix functions currently don’t have many constraints on their inputs doesn’t mean that they couldn’t in the future.

> it's only in the context of an evaluation of a graph node that uses that file that you can infer anything meaningful about it (and even then that information is only relevant in that context)

That’s how nixpkgs works now. But we can make functions that work only in more limited contexts.

Re: We want to make Nix better

#78

Post by wizwit999 »

rgoulter wrote: post #16

I agree with the preamble and the "our mission" stuff. I wish them success at bringing the benefits of nix to more users, but without it being limited to enthusiasts, and people who can afford to deal with rough edges. The "external dependencies" thing shows how Nix can be a tough sell to those who don't click with it. I'd say that the other solutions are: - a README which has a bunch of "apt-get install" commands yo…

How about Bazel, doesn't it solve the same issues?

Re: We want to make Nix better

#79

Post by tadfisher »

tazjin wrote: post #63
tadfisher wrote: post #31

Earlier quoted context omitted.

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.

Some community members have looked into this quite a bit, and personally I have come to the conclusion that types don't really give that much benefit to Nix (and I say this as a Rust & Haskell developer). Nix expressions are almost always[2] short-lived snippets that evaluate to a data structure, not long-running programs where the distinction between "static analysis time" and runtime is extremely relevant. In fact,…

> tooling for auto-completing members of attribute sets

That's a great start, but it would be nice to know what the expected type of the member is! Often it's another attribute set, a list, or even a function, and it's impossible to tell what type is expected without looking at where the member is used.

Re: We want to make Nix better

#80

Post by oxff »

Make the documentation up to the modern standards. If I have to open a single random blog or Github repository to find out what to do and piece it together like a puzzle - it is impossible to adapt at organizational scale.

It is also complex enough to require a modern Language Server.

Post reply on HN