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

91–100 of 205 posts

Re: Nix: Taming Unix with Functional Programming

#91

Post by octoberfranklin »

xyzzy_plugh wrote: post #50
agentultra wrote: post #34

Nix seems great for build servers. This is a great introduction to the motivations behind it. I'm not sold on using it for managing developer environments (another use case it is often used for). It "solves" the problem that developers might be using different versions of libraries or compilers on their machines... but it comes at the cost of having to learn a whole new programming language, a configuration language,…

Hydra is arguably one of the scariest parts of Nix: A giant, bespoke CI system written in C++. Arguably it shouldn't exist. Nix can and should easily slot into any CI tool.

And, unlike nixpkgs, Hydra is pretty unfriendly to contributions.

There is one master trusted public key for nix:

    6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
It is hardwired into the nix source code and every (unpatched) build of nix from the last decade or so. There is no revocation system. There is no public key infrastructure. If that key gets compromised, there is no backup plan. I love Nix, but this is batshit crazy.

The Hydra instance has access to the corresponding private key. So the people who merge changes to Hydra are understandably paranoid. Unfortunately this has turned the codebase into a mess.

Re: Nix: Taming Unix with Functional Programming

#92

Post by SuperSandro2000 »

pxc wrote: post #65
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…

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…

Applications can overwrite dependency versions they want to use. It's just not possible in the python package set because if ever two versions of the same package are in one environment very strange things happen and everything falls apart.

Re: Nix: Taming Unix with Functional Programming

#93

Post by SuperSandro2000 »

nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

That blog post is using nix-env which you shouldn't do if you are trying to achieve more than the bare minimum.

Re: Nix: Taming Unix with Functional Programming

#94

Post by mmcdermott »

smoldesu wrote: post #5
hoosieree wrote: post #2

A few years ago I heard about Nix and NixOS. I loved the idea, but I did not enjoy the experience. Maybe the problem was I was trying to make it work on a less well-supported platform (I think it was ARM32). But the packages I wanted to install either weren't available, or I kept getting incompatibility errors. I still love the idea, but these days I feel like environment managers like Anaconda make (mutable) Python…

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.

Re: Nix: Taming Unix with Functional Programming

#95

Post by SuperSandro2000 »

pca006132 wrote: post #63
nixpulvis wrote: post #13

Nix needs a new porcelain interface for it's CLIs. Moreover, this post sums up one of my biggest issues stopping me from trying Nix for real again: https://ianthehenry.com/posts/how-to-learn-nix/ambiguous-pac... Finally, needing to rewrite everything in Nix is nice for poorly written configurations or undocumented packages in general, but seems redundant for well maintained software. Has anyone else come up with a sa…

I think nix probably needs a more beginner friendly documentation as well, by beginner friendly I mean Linux beginners. Beginners will not read through nix pills (assuming they can understand it) before trying nix, they will just give up. And there are a lot of Linux users who don't have much technical knowledge about how binaries are being linked, etc. I think the ecosystem is now mature enough for beginner users to…

Nix is a programming language and there is no visual editor for it yet.

Re: Nix: Taming Unix with Functional Programming

#96

Post by SuperSandro2000 »

ryukafalz wrote: post #36
jnxx wrote: post #15

Earlier quoted context omitted.

I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…

I much prefer Guix UI-wise but it has some downsides: — I’ve had more jank on Guix System as a desktop OS than on NixOS. Specifically some dbus-related stuff like notifications and appindicators (when running sway + waybar) has been very unreliable for me under Guix in ways that it hasn’t been on any other distro I’ve tried including NixOS. Still haven’t figured out why. - Guix is slow compared to Nix. This is especi…

Guix is also very verbose compared to nix.

Re: Nix: Taming Unix with Functional Programming

#97

Post by pxc »

atemerev wrote: post #88
pxc wrote: post #52

Earlier quoted context omitted.

Overengineered? Maybe, depending on your use case. NixOS is pretty popular as a desktop OS within the community, for example, and I could see a case that its guarantees and strictures are overkill there. But maintenance is really easy. You're basically never forced to rewrite or throw away tons of config. Doing literally years worth of updates at once is typically pretty painless. (Adding new packages to Nixpkgs or n…

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: https://github.com/cript0nauta/pynixify

pip2nix: https://github.com/nix-community/pip2nix

The tools available to you at the time (pypi2nix and maybe python2nix, if it was a long time ago) have been abandoned in favor of the newer tools, I think chiefly poetry2nix but I'm not sure.

There's still the Nixpkgs buildPythonPackage stuff, I think, if your goal is to upstream a lib into Nixpkgs. But if you just want to build your own Python applications and vendorize the deps (e.g., for work), you might try one of the tools above, which weren't available 3+ years ago.

dream2nix is by the author of mach-nix IIRC and has the goal of establishing a unified standard and codebase for ${proglang}2nix type package generators. But mach-nix is still maintained and might be the more feature-complete choice between them.

Maybe Nix-y Python users and developers can reply with some of their experiences using those tools for real projects :)

Re: Nix: Taming Unix with Functional Programming

#98

Post by mr337 »

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/

This is fantastic reading and never really through to use nix for a router.

Re: Nix: Taming Unix with Functional Programming

#99

Post by pxc »

SuperSandro2000 wrote: post #92
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…

Applications can overwrite dependency versions they want to use. It's just not possible in the python package set because if ever two versions of the same package are in one environment very strange things happen and everything falls apart.

Yep, Nixpkgs freely relies on that kind of vendorization to solve compatibility problems in other programming languages' ecosystems when it has to.

And Nix users can totally override specific Python library versions as one-offs for their own Python packages or environments.

It's just really unfortunate that some of Python's internals make that unfeasible for Nixpkgs' collection of Python libraries as a whole. :(

Re: Nix: Taming Unix with Functional Programming

#100

Post by rahen »

ryukafalz wrote: post #36
jnxx wrote: post #15

Earlier quoted context omitted.

I have tried Guix (as a package manager), and it seems much better documented. I also really like the fact that Guix uses a well-established, minimalistic, well-implemented, functional-preferred configuration language, which is Guile, the GNU implementation of Scheme, which is very much tailored to be extended with and embedded in other software, for example written in C. In part, my love comes from having had to use…

I much prefer Guix UI-wise but it has some downsides: — I’ve had more jank on Guix System as a desktop OS than on NixOS. Specifically some dbus-related stuff like notifications and appindicators (when running sway + waybar) has been very unreliable for me under Guix in ways that it hasn’t been on any other distro I’ve tried including NixOS. Still haven’t figured out why. - Guix is slow compared to Nix. This is especi…

GNU Guix, much like Emacs, is a set of LISP (guile) scripts running on top of a small C runtime. Nix is mostly C++ in comparison.

https://git.savannah.gnu.org/cgit/guix.git/tree/guix

Post reply on HN