What Nixos should do is when people download the OS, catch them and do a study. Follow 500 people and see how they fare
1 Like
This.
The overlap between the “old way” and the “new flakes way” created a lot of confusion. When I made the decision to learn and use NixOS, I wanted to dive directly into the modern approach, not learn the old stuff and then re-learn again to use flakes. So I spent a great deal of time over the course of a month trying to sort through which tutorials were useful, which ones looked useful but actually didn’t work for flakes, why something changed, etc.
Another example is trying to use projects like sops-nix, which have a number of different sets of instructions depending on whether you’re using flakes or not, whether you’re using Home Manager and whether are using flakes with it, etc.
If/when flakes becomes official and no longer experimental, I think more people will switch to it and more tutorials/projects will give proper flake instructions. I don’t know if/when that time will come.
3 Likes
I would pay money to be able to do a self-paced Nix course with the different levels you describe. I’m also surprised there are no books on Nix. I only found one on Leanpub (NixOS in production, by Gabriella Gonzalez).
As a very recent Nix user (package manager only for now), I generally agree that navigating the documentation has not been easy. I think that one thing that’s missing are more tutorials. Things like “how to do X”, with clear instructions and links to dig deeper if needed. It’s not always easy to piece together all the different pieces of documentation to know “how to do X” currently.
4 Likes
The official docs won’t introduce Flakes before it’s stable, so I wrote a little book for beginners for this:
10 Likes
OK this looks amazing, thanks for sharing!
I’ve had difficulties “unlearning” things.
My background is in non-functional programming languages, and the choices in the nix language were (and sometimes still are), really hard to understand and, specially, to read.
Same for versioning, most of the tooling I’ve used is based on versions. I think that I understand now, that versions are not necessary in nix, to build a package, it uses hashes. But then, what if I need another version of the software? There’s like an issue there.
Anyways, back to the point, it would be nice to be able to understand how most things work in comparison with the “outside-nix”, and to unlearn.
On top of that:
- I’ve had difficulties with the “old” vs “new” cli
- Finding examples. Nix is not typed, and there’s little documentation. If I’m lucky I may find the api interface (with no examples).
I think it would be nice to have a nix book like the official rust book.
1 Like
I think mostly of the problems IMO is the bureaucracy to merge something. I know it must have some but the nitpicking and what if you use makeDesktopItem and copyDesktopItems instead of >> and cp and the syntax stuff like use a with lib; in meta or not should be enforced by an automation, humans shouldn’t care about this like how something like gofmt -w + some linters look like.
A lot of my PRs got stuck for months and only some of them were merged eventually because of many nitpicking round trips that each cycle took basically at least a day. I always add my brazilian community colleagues and post my PR links on our group so they can do a first glance at least if the stuff make sense. Things happen mostly slowly until Sandro kicks in.
BTW just giving my two cents about how code is referenced and so on, I think all top level withs should be replaced to let inherits so it’s easy to know where some stuff came from. It’s a hell to navigate, for example, in the code related to systemd, like it’s not obvious to find the definition of systemd.services.<name>.script as it is to find the definition of the config files of grafana and also there should be like a pkgs.pkgsUnfree like there is a pkgs.pkgsCross so people can use nixpkgs.legacyPackages to reference packages on a flake or something that doesn’t require a import nixpkgs { config.allowUnfree = true; }.
Another thing that annoys me, even more when I am advertising Nix to my non-Nix-user colleagues is that extra step required to enable flakes and nix-command. Basically it’s just an annoyance that could be a warning at most instead of a hard error. I have an idea and may introduce an RFC to start a discussion around that.
7 Likes
I think if Nixos wants to expand beyond “Geek Boutique”, it should introduce two things.
- Flavours
- Learning Packages
Flavours would be preconfigured instances of Nixos ISOs to download. So people can hit the ground running.
I.E. A Nixos config with a few essential apps already meshed into the config. [e.g. a fully configured Neovim IDE]. Sure, it is dumbing down a bit, but it puts some bottom rungs on the ladder, imo.
I think learning materials should be formalized into packages, and presented through Nix packages.
3 Likes
These kinds of things are an absolute Godsend Ryan. Thank you for all the time and effort you have put in.
2 Likes
Contributing to nixpkgs, is a non-technical because I just see that huge repo, with a lot of contributors and think: Nope!
I’m not confident enough.
It is different from ie. pypi, npm, where I publish my package, if it is good to me is good enough,
Nixpkgs are our packages, and I will touch someone else experience in his OS…
Just thinking, how many packages are there just waiting to his author be confident enough to join our crowd.
1 Like
Everything I read so far really reminded me of this talk from RustConf 2022. Maybe Nix really needs a Product Manager or two? Not sure how much it would help with nixpkgs.
3 Likes
My problem is that I hardly get an answer when posting a problem here on Discourse. I started to get reactions when opening an issue on GitHub or even starting a pull request. Here is one posting still unanswered for months:
I can hardly imagine no-one ever had this problem.
Secrets handling. Even though there are tools to help with this, when you are new to Nix and are struggling to grok the basic concepts, adding the complexity of those tools to the mix becomes overwhelming. My takeaway was to lift out any knowledge of secret values from my nix files. At least then I could script my way to add them “out of band”. It lessened the mental overhead.
I believe future improvements in this area could take advantage of systemd’s credential functionality. Basically, load systemd’s credentials storage with the secret values separately, and only refer to them by reference, not by value, in Nix files
9 Likes
I don’t have much interesting to add regarding the general nature of the Nix ecosystem Ugh field – I think it’s mostly well-grasped by now and is something in the intersection of incoherent overall vision, lack of resources, and unclear hierarchy.
I do observe a couple of things that are currently handled manually and look like they could be (mostly) solved by technical means:
-
It seems that most PRs are package bumps. Can a clear policy be formulated along the lines of “a bump for a leaf package with no patches, performed by the bundled update script (or by a human but that looks like it could be automated i.e. only increases the version string and changes the source hash), and which passes automation, Just Gets Effing Merged”? If not, why? I suppose this touches on the deeper question of “does Nixpkgs want to just package or does it want to curate too”, but the answer to that one should be pretty clear.
-
Regarding other aspects of contribution flow, what would be great is a way for PRs stuck in limbo to bubble up into reviewer/committer attention that does not involve prodding people via side channels (Matrix, Discord, DMs, etc.). The current situation is clearly miserable for contributors and must cause reviewer/committer burn-out.
12 Likes
Related to this: I really struggle with writing flakes because of how unopinionated the ecosystem is and how tricky it is to debug problems. Flexibility is a double edged sword:
- If people can do anything it’s hard to have everyone agree on consistent patterns and it’s easy to get lost.
- you can do anything so it’s very powerful and flexible.
1 Like
The Setting:
In this corner of the internet, we have a lot of Real Engineers™ who will learn a new language if its the right tool for the job. Anyone else would never stick with nix long enough to see the light. So that’s like, a bias we have. Most days, I consider myself a Real Engineer.
But there’s a whole world out there (most notably Science, Finance, and “Data” if that can be called a sector–where I work we think so). A world where code is not king, but instead is just a minor noble. No matter how good it would be for them, they’re never going to learn Haskell. For better or worse, Python is perceived as “good enough”. And you know, it used to be Microsoft Excel that was “good enough”, so perhaps we should be proud of them.
Python is home for me. Its packaging system is an imperative mess, but I still like writing it. Also, I’m a bit tired of writing code that solves code problems which solves code problems which… I want to be nearer a real problem. So my current focus is to find a way to be a bridge between these worlds. How can I help the people for whom Python is good enough, particularly ones that are solving Real Problems™?
Finally, one last bit of context: the threat landscape. The bad guys are getting better and better at being bad. The good guys are getting better too, but not as quickly. That imperative mess that is the python packaging landscape is a great big rug under which people sweep packaging complexity and never look at it again. It’s full of opportunities to bundle malware into otherwise useful packages and not get caught for a good long time.
Us Real Engineers, we’ll be fine. But the others… they brought an umbrella when they needed a tent. The mosquitos are coming and they’re going to be eaten alive–I want to help them. So that’s me (before I got stuck). Perhaps arrogantly, I was going to be the hero that Python needed. I was going to learn nix so well that I could build a bridge for them to someplace safer. (That’s also how I get motivated, if I can’t convince myself that I’m saving the world, I have a hard time getting started.)
The Stuck Part:
I convinced my colleagues to let me maintain a flake.nix in my work repo–it’s not like they have to use it. And for a while it was going well. I found bugs involving dependency on different versions of grep, and other such things. I was making a good case for nix. People would encounter problems that I didn’t have because they invoked homebrew in the wrong way or whatever.
But I never got that flake to look good enough to present to the company in a “we should do this everywhere” kind of way. Two things prevent it:
- https://github.com/astral-sh/ruff-pre-commit/issues/22 (which I reported and don’t know how to fix)
- `pre-commit` can't find modules · Issue #238345 · NixOS/nixpkgs · GitHub (which I introduced while fixing something else)
A seasoned nix user would just avoid these tools, but the people I’m trying to convince that they need nix… they’re not seasoned nix users. If I want to convince them, I need to make these two work.
The Cherry on Top:
While attempting to fix the second bug listed above, I reached out to the package maintainer and asked for some guidance. The way I saw it, I was helping bring his work to a wider audience, I was helping him out. He politely said:
No. I don’t recommend using nix.
I’m not trying to call him out here. He was well within his rights to say no. I can’t fault him for disagreeing with me about how cool nix is. That’s fine. But where I was in my journey, it sounded like:
we don’t want to be saved, thanks
He’s not exactly Guido Van Rossum, but he’s a stronger voice in the Python community than I am. His package is incredibly popular. Maybe he’s right, maybe I’m barking up the wrong tree.
Plus it’s kind of eerie that I broke this incredibly popular package in nixpkgs and haven’t gotten much noise on that issue. It’s got me feeling like I’ve been fighting a lost cause. I’m still learning nix so I can apply it in my own endeavors, but the interaction has sort of took the wind out of my sails when it comes to making a difference in the community.
12 Likes
Joachim Schiele is one of the people I see as ‘Heros’.
Kind of like the French resistance…
1 Like
I’ve almost given up a dozen times due to cryptic backtraces and difficulty in tracing expressions.
12 Likes
Honestly, it’s the nixos and nixpkgs manual. Frankly, I’m going to sound like many of the other people who started out with nix, hit a wall called documentation, and had to climb it: the documentation is neither here nor there.
More specifically, for devs / package maintainers these are my major gripes:
documentation generation from code
doxygen, rustdoc, javadoc, sphinx, docco, and other tools exist, but nothing has been made of the same caliber. Parts of the nixpkgs documention is generated from code, but I always have trouble finding things.
Want a quick reminder of the options available to you in mkDerivation? “Ctrl+F” is your only friend and you have to hit F3 a few times to get somewhere and then manually scroll to places you’re looking for.
too many unspoken rules for nixpkgs PRs
- barely any linting → “Please remove this newline”, “this function doesn’t use the proper case”
- fields in
mkDerivation.metahave minimal descriptions and it isn’t clear when to use the optional fields - package naming conventions aren’t clear. fresh, still, wrapped, unwrapped, bin … what?
I’m missing more, but it’s a pity that PRs get stuck because they have to go through multiple rounds issues that could’ve been checked by a linter.
As a user:
should this be an option?
When I was a newbie, the fact that options existed and simply installed nginx wouldn’t start an nginx service was completely unclear. That’s a simple case though and nowadays I still run into the problem of not know whether a package is actually managed by an option. Some options have a package field which defaults to some package, but there are known, unlisted alternatives which aren’t found by the search.
It would be great to have a warning or field generated in search.nixos.org like usedInOptions.
package descriptions can be confusing
See libreoffice. Yes there’s a description but it’s the same for about 8 packages and I still don’t know which one to install. I went with libreoffice-qt, but I have no idea if that’s the right one. It works, yes, but am I missing something?
This happened a few times and for newbies is probably more frustrating as they most likely don’t want to click on “source”, find out it’s a function that spits out mkDerivation depending on certain input, trace where that input comes from and hope to stumble upon a comment explaining why this input what chosen or not.
the nixos website is unclear
Made an issue for it that hasn’t moved for 2 years
https://github.com/NixOS/nixos-homepage/issues/734
Oh boy… I’ve been using nixos for 2 years already 
9 Likes
One thing for me as a beginner is/was the documentation. I think this kind of stems from Nix(OS) being so fundamentally different to most other distros. I have tried to set up Neovim and/or Intellij for Rust development and just failed, because I didn’t even know where to start (there were different problems for both problems). Which in turn made me switch back to another distro. I am definitely willing to give it another try, but Nix just seems really daunting to get into.