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

What is Nix and why you should try it

yakking.branchable.com

Post reply on HN
Print view View original

191–200 of 201 posts

Re: What is Nix and why you should try it

#191

Post by ben0x539 »

roblabla wrote: post #98
ben0x539 wrote: post #77

Earlier quoted context omitted.

Why shouldn't one prefer the original over some rando's weakly motivated, niche NIH rehash, unless you're already victim to lisp-induced Stockholm syndrome?

> some rando's This is a GNU-approved fork > weakly motivated Has lots of strong motivation, like a stricter stance on non-free software, the usage of a "real", more expressive language (Guile) instead of a niche, poorly undocumented DSL (Nix), use of GNU Shepherd instead of SystemD for the init system, among other > niche NIH rehash It shares most of the codebase with Nix, so to say it's NIH is missing the point. Ni…

I'm curious if you'd like to elaborate on what makes Guile more expressive than Nix for writing package definitions.

Re: What is Nix and why you should try it

#192

Post by ben0x539 »

aprdm wrote: post #189
mrkgnao wrote: post #188

Earlier quoted context omitted.

Um, just to be clear: can I write a program that depends on both A and B? Nix lets you do that.

At the same runtime? No. At different runtimes (e.g: different package.py configurations) yes. I can have a software called my_application which has a version that uses A and another version that uses B. That differentiation can be a flag at runtime, a "variance" e.g: gcc-4 vs gcc-3 etc. How does nix allow you to do that? For example, say I am using library foo and it has the function bar In version 1 bar definition…

I wasn't really thinking about language-level runtimes, like, I don't want to solve the problem of only having one global scope in python and running into module name collisions. I'm not sure how concerned rez is with shell environments beyond what (eg.) python packages are available in it, but I was wondering about having a shell where a program foo is available that, say, requires a lib compiled with gcc-4, and another program bar that requires the same lib at the same version but compiled with gcc-3.

Nix expends a bunch of complexity into fucking with dynamic linking to make that work transparently most of the time and deploying wrapper scripts to cover other cases, so I was curious if rez has a cleverer solution there.

Re: What is Nix and why you should try it

#193

Post by ben0x539 »

k2enemy wrote: post #169
ldlework wrote: post #15

I have recently started looking into Nix to solve the problem of dotfile deployment to new OSX workstations. When you get a new laptop, you clone your dotfiles, maybe symlink them to your home directory -- and then what? Nix solves this problem for me by coupling my dotfile deployment with the installation of the related software. The learning curve has been absolutely tremendous, however. That said, the support on F…

Can you elaborate a bit on how Nix helps you set up your user space? Do you install software with "nix-env -i package" or do you have a declarative way of doing it? If you use nix-env, how is that better than "brew install package"? I'm not doubting your setup, I'm just trying to use nix for the same thing and am having a hard time finding the canonical way of doing a declarative user setup.

For me the part that I'm saying nix-env -i rather than editing a config file and nix-whatever --read-the-config-file-again isn't really a big deal. It's just a cute tool to author and maintain user environments, I'm sure I could, like, define a single package that just depends on and exposes all the packages I actually want installed and call that my declarative user environment but I'm not sure what that's actually gaining me.

Declarative or not, I'm still gonna get the advertised benefits of Nix like, say, having some confidence that I got all the dependencies specified properly if my stuff builds, easily customizing packages by overriding specific bits, and coping with arbitrary version requirements really easily.

I'm sure someone who's more used to configuring homebrew has a different perspective there, but it definitely seems preferable to taking over /usr/local and rotating things in and out of there as I switch between projects or w/e.

Re: What is Nix and why you should try it

#194

Post by ben0x539 »

asymmetric wrote: post #190
k2enemy wrote: post #170

Earlier quoted context omitted.

Thanks for linking to this! Do you know of a way to get a list of installed packages then? "nix-env -q" lists the meta-package but not the packages installed within. Also, when you update packages, does the update propagate to the sub-packages?

Yes, `nix-env -iA` always installs the latest of all the actual packages I have listed there. And as you can see you can also override their config. I don't know how to list installed packages, as I almost never feel like I need to know that (but if you find out how, I'd be happy to know!)

I'd expect you list installed packages by pointing your text editor at the file where you defined which packages you want your meta-package to pull in, no?

Re: What is Nix and why you should try it

#195

Post by ben0x539 »

taktoa wrote: post #96
bfrog wrote: post #76

Earlier quoted context omitted.

Try packaging a postgres extension :-)

If you tell me which specific piece of software you tried to package, I can probably explain what is going on. I strongly suspect that it is either not Nix's fault, or an inherent tradeoff in packaging software (i.e.: not a design flaw, but simply a result of the correctness of package expressions being more tightly controlled in Nix than in other languages). The main exception to that statement that I've seen are ca…

What's the status of recursive nix / people's thinking about recursive nix?

Re: What is Nix and why you should try it

#196

Post by aprdm »

ben0x539 wrote: post #192
aprdm wrote: post #189

Earlier quoted context omitted.

At the same runtime? No. At different runtimes (e.g: different package.py configurations) yes. I can have a software called my_application which has a version that uses A and another version that uses B. That differentiation can be a flag at runtime, a "variance" e.g: gcc-4 vs gcc-3 etc. How does nix allow you to do that? For example, say I am using library foo and it has the function bar In version 1 bar definition…

I wasn't really thinking about language-level runtimes, like, I don't want to solve the problem of only having one global scope in python and running into module name collisions. I'm not sure how concerned rez is with shell environments beyond what (eg.) python packages are available in it, but I was wondering about having a shell where a program foo is available that, say, requires a lib compiled with gcc-4, and ano…

Oh yeah, it is certainly possible.

you have build_requires which you can list dependencies that you require at build time (e.g: gcc-3 vs gcc-4) but not at runtime.

So you can have things that were built with gcc-3 and gcc-4 running side by side in a same shell environment without issues.

gcc itself, in this case, would be a rez package that can have multiple versions installed in the system.

Re: What is Nix and why you should try it

#197

Post by mrkgnao »

aprdm wrote: post #189
mrkgnao wrote: post #188

Earlier quoted context omitted.

Um, just to be clear: can I write a program that depends on both A and B? Nix lets you do that.

At the same runtime? No. At different runtimes (e.g: different package.py configurations) yes. I can have a software called my_application which has a version that uses A and another version that uses B. That differentiation can be a flag at runtime, a "variance" e.g: gcc-4 vs gcc-3 etc. How does nix allow you to do that? For example, say I am using library foo and it has the function bar In version 1 bar definition…

Essentially, Nix treats every version of a package, or every "instance" of a package compiled with different flags, or different "build inputs", as a completely different dependency. So foo-1.0, foo-2.0, and foo-2.0-debug are all separate things you can depend on, from the POV of the package manager. A huge "symphony" (a friend's term) of symlinks holds it all together.

Re: What is Nix and why you should try it

#198

Post by rekado »

arianvanp wrote: post #158
jancsika wrote: post #138

Earlier quoted context omitted.

Does the Guix choice of a more expressive language for defining the packages help here?

No. I think both languages are equally expressive in the end (though one will be a bit uglier than the other). But the problem is probably less big in Guix because only a few graphics drivers are actually supported due to the fact that all the drivers needs to be Free and free of binary blobs.

> But the problem is probably less big in Guix because only a few graphics drivers are actually supported due to the fact that all the drivers needs to be Free and free of binary blobs.

This is a property of Linux libre, not of Guix per se.

Re: What is Nix and why you should try it

#199

Post by nerdponx »

programmer_dude wrote: post #187
nerdponx wrote: post #61

Earlier quoted context omitted.

these functions' documentation is either buried in a long manual This is a problem with lots of feature-rich software, even with meticulously-documented APIs. What we need is reverse-indexed documentation. That is, an extensive API reference is only useful for someone who already knows what functions are in the API and just needs to remember how to use them. But even the most thorough API reference does nothing to pr…

This just looks like you missing things like classes, namespaces etc. in C. Classes, namespaces etc. are a natural way of making API discoverable (among other things). For example if you want to know how to search for a somthing in a string just look at the methods exposed by string.

Then you just pass the buck over to classes and namespaces. You have the same fundamental problem in Ruby and Python, perhaps even worse for lack of typed function signatures.
Post reply on HN