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

Nix: Taming Unix with Functional Programming

tweag.io

Post reply on HN
Print view View original

101–110 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#101

Post by SuperSandro2000 »

infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

The python ecosystem is not a giant mess, its just dependency hell. You need to work with what you get from upstream.

> Nix actually integrates all package updates into one channel which nobody else anywhere does

If you are using the python system packages then Arch, Debian and probably more are doing the same.

> it's even worse because a lot of projects use python as a build dependency (?!) which then cascades these issues even farther.

In practice this is not a problem at all. Build systems that use python underneath have usually very little dependencies. The bigger problems we are facing are big python (web) applications and anything that moves (very) slowly upstream like (sadly) many AI/ML projects.

FYI: I am very active NixOS maintainer and one of my foci is the python packages in NixOS.

Re: Nix: Taming Unix with Functional Programming

#102

Post by bogota »

octoberfranklin wrote: post #85
bogota wrote: post #59

Earlier quoted context omitted.

I dont think anyone is being negative at least not the top level comments i read. I like nix but i gave it a test run at my company and no one could figure out how to make any change that wasn’t a copy and paste of what i had done. The docs don’t help much unless you really go diving into them and most people who just want the software to run don’t want to spend the time learning it. I don’t blame them. This is a ver…

> most people who just want the software to run don’t want to spend the time learning it these people are not nix's target audience

I personally think that is a bit of a cop out. Most developers should be able to do basic tasks in a system that has been setup by an expert user.

I think bazel is an ok example of this. Its a pretty complex build system but expert users can build macros and rules that the average developer can consume without having to know a ton about everything that is happening.

IMO the ability to do the above at some level is the sign of well crafted software.

Re: Nix: Taming Unix with Functional Programming

#103

Post by smoldesu »

mmcdermott wrote: post #94
smoldesu wrote: post #5

Earlier quoted context omitted.

I use Nix on an array of devices (any combo of x86/aarch64 and Linux/Darwin machines you can imagine), and while I really do love the experience, you're right that ARM is a sticking point. It's been getting better over the past few months, but still not close to x86 packaging parity. On the other side of that coin, I tried switching back to Arch a few weeks ago after ~4 months of NixOS. Maybe it's the sunken-cost fal…

Is there a way to get it so that UI applications installed with Nix show up in Spotlight Search? I remember that being my big annoyance when I tried using Nix instead of Homebrew on MacOS.

Oh, I wouldn't know (my Mac is a dumb terminal for testing and nothing else). They should have appropriate .desktop files for their Linux counterparts, though.

Re: Nix: Taming Unix with Functional Programming

#104

Post by otabdeveloper4 »

octoberfranklin wrote: post #86
otabdeveloper4 wrote: post #71

Earlier quoted context omitted.

Nix is not an operating system. It can be used to build operating systems easily, though. Also, there isn't anything "functional" about Nix. It's a nice sales pitch, but underneath it's just a thin layer over bash scripts and environment variables.

Nix is a metaprogramming language for bash. The metalanguage is indeed purely functional. The object language (bash) isn't.

Right. You still end up mostly writing bash scripts when wrangling Nix. It's not some sort of ivory tower Haskelish hermetic ecosystem, it's just a very nice way to make bash scripting sane.

Re: Nix: Taming Unix with Functional Programming

#105

Post by lamontcg »

jnxx wrote: post #76
infogulch wrote: post #62

Nix is running face-first into complexities of build and package managers. As an observer it looks like Python's package ecosystem in particular is a giant mess . This affects Nix disproportionately because Nix actually integrates all package updates into one channel which nobody else anywhere does (and I guess package authors often don't care to fix), and it's even worse because a lot of projects use python as a bui…

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem.

Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and break backwards compatibility.

Re: Nix: Taming Unix with Functional Programming

#106

Post by qbasic_forever »

jnxx wrote: post #73
pxc wrote: post #65

Earlier quoted context omitted.

Yeah. This is covering stuff you know if you've read that thread, but: Putting all Python libs into a single channel is something Nixpkgs does because Python can't handle different versions of the same library in a single process. The Python libs that are used in actual applications in NixOS, then, need to be compatible or they might cause weird issues when a new or existing package tries to leverage them at the same…

> The Python community faces some really tough institutional/governance/adoption problems The Linux kernel people could have the same problems... it is genius how they have solved them, by developing git but also by establishing processes that scale.

In the Linux kernel world Linus is the final arbiter and decision-maker--he takes input from people he trusts but ultimately he and only he has the final commit. Python used to have this model too with Guido at the top as the "BDFL" (benevolent dictator for life), however when he stepped down they replaced it with a consensus of a steering committee: https://peps.python.org/pep-0013/ Both projects have very different governance as a result.

Re: Nix: Taming Unix with Functional Programming

#107

Post by mistahchris »

euroclydon wrote: post #75

I built my router and NAS from NixOS. It was a mostly pleasant experience. Being able to sit in an IDE on my laptop, and build up a server, incrementally pushing changes to it, with rollback if necessary, was great, and I wouldn't want to go back to anything else. I wrote about the router here. It's pretty heavy on router stuff, and my own thoughts though... https://www.jjpdev.com/posts/home-router-nixos/

Wow that is cool. I have been wanting to build both a router and a NAS and run nixos on them since I run nixos for everything else I do. Thanks for writing and sharing about your experience!

Re: Nix: Taming Unix with Functional Programming

#108

Post by infogulch »

lamontcg wrote: post #105
jnxx wrote: post #76

Earlier quoted context omitted.

> As an observer it looks like Python's package ecosystem in particular is a giant mess. Most people would say it is. The better question is how to avoid such a mess. My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. And yeah, that has also become a cultural issue with Python, as the Python2/3 breakage shows. So, could one sum it up in th…

> My take is that maintaining backward compatibility is a core principle which needs to be strictly observed to solve that problem. Given that software developers never guess the correct design up front this means that you always have architecturally buggy software, and a bunch of complaining about why buggy-looking edge conditions are never fixed. There has to be some kind of release valve for software to evolve and…

Yes they've invented that: It's called bumping the major version.

Re: Nix: Taming Unix with Functional Programming

#109

Post by idealmedtech »

Back in college, the engineering school had a farm of Linux servers from which you could access all your documents, as well as log in to your account from any number of computer labs around campus. Back when I was first learning Linux (not that long ago, 2008), I fell in love with how many things you could customize, and really create your own experience. When I got to college, I wanted to replicate this ability (install ANY program! use ANY desktop environment!), but predictably, their machines were pretty locked down.

I went snooping around the internet, and found that there was this magical software called Nix, which would let you have a package manager without root! The Linux computers in the lab didn't have root, but they did have GCC. I started learning all about build systems (mainly that you could specify a custom --prefix and essentially create your own filesystem within your filesystem), and got to work compiling Nix (or, i think, GUIX) from source. It's actually a fantastic amount of work to go from GCC all the way to a functional GUIX, even with access to every source tarball on the Internet

Eventually some admin emailed me about this project and I stopped working on making it happen shortly after, but it was such a formative experience in my tech life that I always think back fondly on it when Nix pops up.

Re: Nix: Taming Unix with Functional Programming

#110

Post by mistahchris »

pxc wrote: post #97
atemerev wrote: post #88

Earlier quoted context omitted.

I tried using NixOS a few years ago. Everything went fine, except Python packages. There has been quite a lot of incompatibilities, sadly.

There are some different/new tools for creating your own Python packages these days. It's still not truly solved in the sense of having a single clear winner , but one of these new package generation tools might serve you better: poetry2nix: https://github.com/nix-community/poetry2nix mach-nix: https://github.com/DavHau/mach-nix dream2nix: https://nix-community.github.io/dream2nix/guides/getting-sta... pynixify: http…

I have used plain nixpkgs, poetry2nix and mach-nix for packaging "real" projects. My biggest take away is that python packaging is a hot mess. This isn't exactly news that no one has heard before though.

The initial work for packaging a complicated python app is dominated by sorting through a lot of confusing errors, no matter what tool you use. poetry2nix and plain nix has been my best experience so far in python packaging though.

For my simple python packages, I'm using plain nix and flit, which has been the simplest. It's not feasible for python applications that need complicated dependency version resolving due to python dependency pinning though.

Here's the plain nix + flit example that I really like: https://git.sr.ht/~averagechris/deduper/tree/main/item/flake...

The poetry2nix projects I have worked with are closed source sadly so I can't link them.

Post reply on HN