[colinramsay]

> I'm going to keep using it, since I can't stand anything else after having a taste of NixOS

This is how I feel about NixOS. I like what it gives me but I don't really like much else about it. Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure. Off the top of my head there are a couple of things I've hit a dead end on recently:

- Packaging a Flutter desktop app because its build process downloads fonts from a URL and so makes the whole thing impure

- Getting Blender's GPU support working, I think the same problem is causing Webcamoid to crash on launch

Previously I used Arch, which I loved, but it was all to easy to completely shaft my setup and not be able to roll back.

[vasergen]

> Unless something _just works_, you're looking at hours of debugging which will most likely lead to failure.

Exactly my experience, in this case I simply switch to my OS package system (I use Nix only as a package manager on my Ubuntu). I think, I have round 95% of software coming from Nix, for the other 5% that doesn't work out of box, I just do 'apt-get install'

Also, for installing different programing languages I switched from Nix packages to 'asdf', because packages on Nix often not up to date if I want to try recent release.

[ashtonkem]

I think they were using NixOS, not just Nix, which means that you can't fall back to the "OS package system" because Nix is the OS package system.

The difference between Nix and NixOS was a branding mistake by the Nix team. It's unnecessarily confusing.

[marcus_holmes]

I just switched away from asdf (primarily developing Go on Mac) because of the problems it caused.

[codethief]

What problems, if I may ask?

[marcus_holmes]

working on multiple projects with varied versions of Go from 1.16.1 to 1.17.6. Asdf would switch versions (mostly correctly) for each project, but then the VSCode tools would not and VSCode would refuse to run tests because there was a mismatch between tool version and Go version.

Golangci-lint was also a nightmare around versions, and I suspect asdf was involved in this, too. We had 4 separate instances of it (the one VSCode used on save, the globally-installed version we could invoke from the CLI, a dockerised version that supposedly emulated what the CI engine would do, and the CI engine itself). None of these ran the same versions of the linters with the same config and the same version of tools.

I uninstalled asdf and used a more conventional version manager. Although there was some pain about remembering to manually switch versions, it actually didn't matter that much. Go's backwards compatibility guarantee meant that I bumped into way less problems from working on a 1.16 project using Go 1.17 than I did from asdf trying to match versions. The important bit was that the tools and the Go version used matched.

[codethief]

Did you try teaching VScode about the right version of Go by having it call `asdf exec go` instead of `go`? (Not sure this is possible with VScode but I'd be interested in whether this might be a way out.)

In any case, aren't those issues more of an IDE problem, though? IntelliJ is the same, and the tools you set for one project might even leak into other projects. It's one of the reasons I hate IntelliJ so much.

[nine_k]

I'd say that packaging an app for NixOS should include rewriting all such impure steps, and making the fonts packaged along with the app is one such step.

If the fonts can't be packaged for licensing reasons, even as a separate package, then well, you indeed can guarantee that you'd be able to install the app next time. If it's not what you seriously need, then likely the value proposition of Nix is not for you.

[colinramsay]

I agree. That doesn't negate the fact that it took me a while to understand what the issue was, see if I could get around it, work out how to disable the font downloading in Flutter, etc, etc. I may have been trying to force a round peg into a square hole but NixOS didn't do much to help me see the shape of the pegs and holes in the first place.

[CyberShadow]

> Previously I used Arch, which I loved, but it was all to easy to completely shaft my setup and not be able to roll back.

Here is my attempt at solving this problem: https://github.com/CyberShadow/aconfmgr

[Ambroisie]

I remember reading about your project a previous time NixOS had been mentioned on HN, and tried to look for it again but couldn't manage to bring up the correct set of keywords to find it.

Thank you for posting it again. I don't think I'll go back to Arch unless I grow tired of NixOS, but if I do I'll be sure to give it a spin!

[colinramsay]

I'm going to look into this, thank you.

[colordrops]

This was a dumb choice by the flutter team. Yes, Nix doesn't provide an easy workaround, but let's not put all the blame on Nix.

[JamesSwift]

Nix 'flakes' aim to address your first issue by requiring all inputs be explicitly defined (including nixpackage itself).