I am a second year computer science student and Linux user that has been using nix for the last five months. I have been enjoying how solid NixOS is as a Linux distribution since I have never had to reinstall NixOS on my machine and can cleanly change core components of my environment. That along with the centralization of config files has made it where I don’t want to give up my Nix anytime soon.
The problem that I have been having is just how painful it is to build github projects and personal code on NixOS. Whenever I try to code on my local machine I keep shuffling back and forth in between dependency/package not found messages and the nix-pkgs website trying to get all of the pieces together into a shell.nix.
What I am looking for is some type of tool so I don’t have to do my programming in a VM sandbox to hide from NixOS constantly trimming my dependencies. Since I am but a simple programmer, a solution that doesn’t require learning the entirety of the nix programming language would be great.
Any tools, talks or articles on the subject would be welcome. I just want to be able to run my crappy projects in peace.
I feel your pain. I’ve been using nix for a few years now and I still have a lot of trouble getting new projects started because some dependency or another doesn’t install cleanly. I end up spending all of my spare time trying to understand whether to engage with the dependency maintainer, or fix it in nixpkgs, or maybe there’s a ____2nix package out there that needs a special entry to handle this package differently. It totally sucks.
But it still sucks less than the alternative. I’m hardly a wizened graybeard of nix, but my experience so far has been that if you walk this path long enough you’ll start finding that some of the packages that you used to trust blindly are now not looking so trustworthy after all. The packaging problem that nix solves head-on… it’s a hard problem. People get lazy and end up shipping part of that VM that they like to develop in as part of their products, and they’ve been doing it for decades. It’s a minefield out there.
Just the other day I was trying to nixify a C++ project published by the NCBI (a government agency) and I found a place where the author had bundled in a TLS implementation because “maybe the user’s version is out of date”. I bet that this guy was just trying to help some poor user out there whose OS was indeed out of date. I don’t think it was part of some kind of Big Brother scheme to spy on scientists in biotech. But intentions aside, here we have a government saying “use our crypto and not yours”. That’s a situation that’s ripe for abuse. At least with nix, we notice. Most other ways of packaging software just help hide things like this.
I don’t have much advice for lessening the pain besides:
Be sparing about what you depend on.
And maybe:
The nix community diverse, most of it can’t help with your language of choice. Instead let’s build community around the specific thing you want to use nix for.
But as far as enduring that pain goes… I find it comforting to reflect on how nix–even though it’s hard–stops the bleeding. If we as a community can demonstrate that it’s a viable alternative to the packaging nightmare, it’ll be an end to the era where software stops being useful when its last dev retires. That’ll be huge, and if we don’t do it, we’re going to have to live in a world where it hasn’t been done. So like… it’s painful, but it’s also important.
I feel it too. I think this is the biggest problem Nix has that severely restricts it from wide(r) adoption. I solved it by having a dual boot Manjaro and Nixos.
When I want to freely develop something I boot into Manjaro and when I want just do something that’s not development then I boot into Nixos. But this only the simplistic part of my journey I want to move over to Nixos eventually but I’m not there yet and I am not in a hurry.
I have found many useful resources for learning Nix but one of the best is Nix Hour. I am interested in learning, developing Python but trying to build in Nixos is not easy, esp for beginners. So I created an issue for Nix Hour and the maestro himself (infinisil) showed the process and produced a script on how to do it. See link. Not only that but there are lots of other videos in the series that are helpful.
Also, I have installed Nix on Manjaro and can do stuff I just want to try to further familiarize myself with Nix.
I suggest A tour of Nix and the Wiki. These are two you will not find that have a high recommendation but IMO are worthwhile. And you can edit the Wiki if you find errors.
I found this link for FHS on Nix, but its not perfect.
As I see it there is no easy way to overcome this problem and asking or expecting the Nix developers to provide some sort of a resolution isn’t going to happen as they are too busy on ‘difficult’ problems right now.
Nix is primarily a tool for software developers. Learning the Nix language currently is the way to make best use of the Nix ecosystem, as most of the interesting functionality is written in it. I know very well how it all seems very confusing. But it should be the smallest part of the learning effort. It really is a small and simple language (modulo some dark corners you likely won’t ever have to care about). The perceived complexity still comes from the jungle that is Nixpkgs and the module system used for NixOS, Home Manager, nix-darwin, devenv, and a few other tools, that feels like magic until you run into a good explanation and get some exercise with it.
But you don’t even have to use NixOS to benefit from Nix! On nix.dev the documentation team is currently building up an onboarding path that follows this paradigm. Did you have a look at our introduction to the Nix language? Nix language basics — nix.dev documentation
At the end it features a bit of an overview of the ecosystem around it.
The situation around Python packaging is indeed not great, which is due to peculiarities about Python itself, how Nixpkgs currently deals with that, and that it’s not very well-documented. We have some work going on in the documentation part, but it’s a nasty problem.
It’s still work in progress, but NixOS and pure, declarative configuration will eventually be framed as an intermediate-level topics because it requires learning more concepts and patterns. For example, we’re currently working on a very comprehensive tutorial for working with the module system: Module system deep dive tutorial by infinisil · Pull Request #645 · NixOS/nix.dev · GitHub
Would be great if you have feedback on whether what we’re doing helps solve some of your problems. There is still a lot of work to be done, and we have some of that already in the pipeline.
When I started I really only did enough research to write my configuration.nix and a home.nix and have been coasting on that ever since. Looks like I’ll be hitting the books. Thanks for the links.
I really recommend learning it properly, even if at the moment the materials are still incomplete or of insufficient quality (we‘re continuously working on improving that). I’ve heard enough people say “users just hack their way through samples until they somehow figure it out, so provide more samples”, and I know that’s how people think and sometimes that’s good enough.
But Nix, and in particular Nixpkgs and NixOS, is different enough from everything else, especially if you’re not familiar with functional programming, that it’s really worth learning it properly, from the very basics.
For me “learning properly” often requires starting from a working example.
I share OP’s frustration: NixOS is awesome, but learning a new programming language on it is awful. And I believe that’s because I hit dependency/packaging problems earlier in my journey than I can or want to understand them.
The worse is when trying libraries that need some system dependencies, forcing me to invest time before deciding whether or not I’ll use them.
Sure, more expertise in Nix / Nixpkgs / Linux helps. The feeling that once it works it can be shared “as-is” also help. But it’s distracting at a bad time and I suspect there will always be language/tool specific knowledge to acquire.
In an ideal world all open source projects would be nix-ready. Until then “more samples” is still my preferred path for learning programming with Nix.