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

My experience with NixOS

blog.patchgirl.io

Post reply on HN
Print view View original

81–90 of 95 posts

Re: My experience with NixOS

#81

Post by takeda »

iso-8859-1 wrote: post #76
takeda wrote: post #56

Earlier quoted context omitted.

What you are trying to do doesn't look like an overlay, but an override[1]. you can do something like this: let new_electrum = pkgs.electrum.overrideAttrs (oldAttrs: rec { name = "${oldAttrs.pname}-${version}"; version = "4.0.0a"; src = fetchurl { url = "https://download.electrum.org/${version}/Electrum-${version}.tar.gz"; sha256=pkgs.lib.fakeSha256; }; }) in Unfortunately there is no https://download.electrum.org/4.…

You can use GitHub's automatic generation of archives even for specific git commits. There is no version 4.0.0a of Electrum, it has not been released, it is misleading to refer to it.

There's actually fetchFromGitHub which takes care of it, looks like parent already figured it out:

https://news.ycombinator.com/item?id=22883382

He also needed to change some dependencies so it's more complex than what I wrote.

Re: My experience with NixOS

#82

Post by takeda »

iso-8859-1 wrote: post #77
therein wrote: post #53

Earlier quoted context omitted.

Thank you. I was able to move forward similarly as well. Good to see the solution I arrived at isn't too far from yours. self: super: { electrum = super.electrum.overrideAttrs(old: rec { preBuild = old.preBuild + '' # Patch unnecessarily tight dependency on ecdsa version substituteInPlace ./contrib/requirements/requirements.txt --replace 'ecdsa>=0.14' 'ecdsa>=0.13' additionalInputs = with super.python37Packages; [ py…

how do you know the dependency bound is too tight?

yes, it's possible that there was reason for requiring newer version, especially since it is a bitcoin wallet and this looks like a cryptographic library.

The better way would be to also update that package to required version.

Re: My experience with NixOS

#83

Post by sterlind »

Ericson2314 wrote: post #72
takeda wrote: post #64

Earlier quoted context omitted.

Agree, nix itself is actually fairly simple. What it is hard though is functional programming, an that's the biggest road block for developers that are used to imperative programming. Places that use functional language for their code base don't have problems picking it up. It is especially big in Haskell community, because Haskell is also lazily evaluated. People might wonder why not use language that more people ar…

Yes people often blame the Nix langauge when they should blame Nixpkgs. I needs some more refactoring than we've been able to give it (though thankfully we've been able to give a lot of refactoring in absolute terms). I think static types what's needed to get us over the hill on this one.

I lay the blame with the arcane and inconsistent design patterns in nixpkgs, and with the usability of the nix toolset. for instance, a number of times I've had packages fail to build due to 404s. I first tried to git clone nixpkgs and fix it there, but I had to set it up as a channel for that to work. next I wasted a day setting up an overlay, but I couldn't get the hang of the self: super: construct. finally I found that for this package it had a flag I could pass for a custom source package, but another package didn't have that, so I had to use overrideAttrs and worry about what builder phase that would apply to etc. etc.

I shouldn't have needed to do this anyway - the nix team should run a mirror for external URLs, except there's no way I see to tell nix to use a mirror without editing all the URLs to point there.

making mirroring bots or connectors to other package indexes, e.g. npm2nix, is a painful experience. it's also frustrating to have to inline bash scripts to build packages.

one of the things Guix got right that Nix didn't, IMO, was using a capable language where implementing these patterns is easy, and using guile scheme instead of bash to actually build the packages. a Guix-like OS with the breadth of nixpkgs would take over the world - I hope both projects can learn from each other.

Re: My experience with NixOS

#84

Post by slightwinder »

rudolph9 wrote: post #33
mbakke wrote: post #29

Earlier quoted context omitted.

GNU Guix 1.1.0 was released just hours ago, so now is a good time to try it: https://news.ycombinator.com/item?id=22877788 :-) Rumor has it that Guix will be included in a future Debian release too. It is already available in Arch, Gentoo, and OpenSUSE.

It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.

How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?

Re: My experience with NixOS

#85

Post by nialv7 »

chongli wrote: post #62
downerending wrote: post #59

Earlier quoted context omitted.

> I recently switched to NixOS and have essentially configured my OS from scratch in less than a week That doesn't exactly scream ease of use .

NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.

> in one declarative file

Which is not always up to date, and exposes all the available options. I found myself often need to dig into nixpkgs and add missing options myself during the time I was trying out NixOS.

And believe me, that wasn't a pleasant experience.

Re: My experience with NixOS

#86

Post by Shoue »

slightwinder wrote: post #84
rudolph9 wrote: post #33

Earlier quoted context omitted.

It’s really great that functional package managers are getting all this attention! Nix package manager can run on Arch and Gentoo and OpenSUSE also.

How does using nix on other distributions work? Can it access their local packagemanagers and install the distribution-packages, or is it a parallel world that just happens to live on the same machine?

It's a parallel world. The other package managers are too imperative to deal with in a declarative manner and would just be painful, though there are attempts to do so (outside of Nix). Nix installs everything to /nix.

Re: My experience with NixOS

#87

Post by throwaway894345 »

takeda wrote: post #71
throwaway894345 wrote: post #66

Earlier quoted context omitted.

It's not Nix's fault, but that doesn't make it cheaper to deal with. Whatever you want to say, `pip install psycopg2` just works because someone else already dealt with the packaging problem.

That's the cost of full reproducibility though. If Nix would not expect the postgresql package listed in dependencies and instead relied on what's currently installed on your system we would get to the starting point. Where something works on one person's computer but doesn't on another. Yes it is harder, but if you incorporate nix definitions in your source code (you need to pin nixpkgs though) then everyone will ge…

There are other ways to get enough reproducibility without the headaches of Nix, however, so that’s what we ended up doing. Reproducibility is nice, but if we need to be able to develop software quickly and for the time being, Nix is an impediment. As previously mentioned, this doesn’t have to be the case; it’s mostly an artifact of lack of documentation and a strong preference for the novel and unfamiliar over the familiar, but also for lack of escape hatches.

Re: My experience with NixOS

#88

Post by takeda »

throwaway894345 wrote: post #87
takeda wrote: post #71

Earlier quoted context omitted.

That's the cost of full reproducibility though. If Nix would not expect the postgresql package listed in dependencies and instead relied on what's currently installed on your system we would get to the starting point. Where something works on one person's computer but doesn't on another. Yes it is harder, but if you incorporate nix definitions in your source code (you need to pin nixpkgs though) then everyone will ge…

There are other ways to get enough reproducibility without the headaches of Nix, however, so that’s what we ended up doing. Reproducibility is nice, but if we need to be able to develop software quickly and for the time being, Nix is an impediment. As previously mentioned, this doesn’t have to be the case; it’s mostly an artifact of lack of documentation and a strong preference for the novel and unfamiliar over the f…

What other ways?

If you don't specify essential dependency and rely on the dependency to be installed that by definition is not reproducible.

The fix in Nix for psycopg2 is specify that it also depends on postgresql, and that's all what's needed.

Here's definition of psycopg2 from NixPkgs: https://github.com/NixOS/nixpkgs/blob/master/pkgs/developmen... (the highlighted part is the only thing that's needed everything else is just informational, doCheck is to control whether unit tests should be run during build and disabled = isPyPy tells that psycopg2 doesn't work with PyPy, which it doesn't work with, because PyPy doesn't support C extensions)

Re: My experience with NixOS

#89

Post by takeda »

nialv7 wrote: post #85
chongli wrote: post #62

Earlier quoted context omitted.

NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.

> in one declarative file Which is not always up to date, and exposes all the available options. I found myself often need to dig into nixpkgs and add missing options myself during the time I was trying out NixOS. And believe me, that wasn't a pleasant experience.

Not sure if it was available when you tried, but this is useful when configuring, it is processed from nixpkgs and indexes all options that are available: https://nixos.org/nixos/options.html

Re: My experience with NixOS

#90

Post by sjagoe »

downerending wrote: post #63
chongli wrote: post #62

Earlier quoted context omitted.

NixOS isn’t easy to use. It’s very powerful though. It gives you the ability to configure your whole OS, including all of your packages and configurations, in one declarative file. It reproduces the entire installation from this file in a way that’s fully immutable and hash-perfect (with minimal building from source). Very cool.

It does sound pretty awesome. Maybe I'll try a hit with VirtualBox.

I tried that initially but never spent enough time using it in a VM to really learn it.

In the end, I just decided to take the plunge and set it up as my main OS after a year of procrastinating around trying it out. I've been using it for about 4 years now, and wouldn't go back to a traditional distro.

And finally, 4 years on, I just set up a new laptop and it was much easier than its ever been before. I just had to copy over my existing nix config, and nix built out the whole configuration and my user environment (with home-manager [0]). It's always been a bit of a pain setting up my profile before this, and maintaining my .emacs.d, etc; now it's all managed.

[0] https://github.com/rycee/home-manager

Post reply on HN