Mine is a bit technical: I don’t have means to testing Darwin things, and to be honest I am not interested in buying an Apple machine, it is too expensive to me.
However, it is tiresome to look at those timeouts from Ofborg compiling LLVM on x86_64-darwin from scratch and/or a job running days along in aarch64-darwin.
TL;DR lack of formal guidelines + too many informal ones for nixpkgs, which leads to bikeshedding, along with not-so-positive experience here either.
I participate mostly by reviewing others’ PRs to nixpkgs. Recently, I decided to submit my own PR to nixpkgs (first contribution). Simple version bump, and added myself as a maintainer, since I use the software, the existing maintainer was nowhere to be found, and they had missed several version bumps. Also went through and made several changes based on a) what I’ve observed on other PRs, and b) whatever ofborg complained about (I used the anonymised GH email in my maintainer block, which I then removed to pass CI). Everything in the PR was also compliant with the contributing guidelines, and I went the extra step of doing testing that many other PRs do not do. I’ve packaged elsewhere since over 11 years ago, so I understand most of the time even nitpicky-sounding guidelines are there for a good technical reason.
No response for a few weeks, which is not something I’m too frustrated about, as I know the PR-to-committer ratio is far too high (and sustainabillity of nixpkgs is a whole discussion unto itself), other than it feels a bit weird waiting for an uncertain amount of time. (Even an estimate of backlog would be more reassuring, although I get why this can be difficult especially if a PR comes through that forces treewide changes.)
Got a couple drive-by approvals. When it came time for someone with committer access to approve, they had no problem with the technical details; however, they instead responded with something along the lines of “I won’t block this PR, but please let me know if you can provide some contact info - I will wait until your response before merging”. To me, since this is not a requirement in the contribution guidelines, it is therefore my prerogative to (not) provide contact info. It’s also quite obvious that I’m not following the format of every other maintainer block, surely there is a reason for this. So I strongly dislike that a committer took it into their own hands to enforce their own standard that is not required anywhere. And they also claimed that they would “not block the PR” but effectively proceeded to do exactly this.
Anyway in this case, I am in between email providers, and I have no interest in participating in matrix, but I am happy to make myself available on PRs if tagged. I responded as soon as possible with this info; I got no response afterwards.
This goes into my other frustration: if I submit a PR to nixpkgs, I have no assurance that what I send will get approved even if it follows all the formal and informal guidelines, since every reviewer will come up with their own pointless requests. If something is a standard, it should be written down. Staring down the barrel of years of bikeshedding over future minor changes, I instead opted to close the PR (after a few more days of waiting) rather than wait around X more weeks for another committer to complain something more on a 4 LOC change that I already spent several hours on. This wastes my time and the time of the committers to do this back-and-forth over nothing.
Most recent thing that soured me a bit was getting a weirdly passive-aggressive response from a longtime contributor to my first comment on Discourse, after which I tried to make a good faith reply but got ignored entirely. I don’t want to call this a “cultural” issue as I don’t follow Discourse much, but I don’t feel great about participating further in the Official Nix Ecosystem based on the timing of it (soon after the PR issue).
I’m not entirely hopeful about even this thread improving things, but I thought I might as well mention something from a POV that I don’t see shown above.
Signing - it’s not clear to me who signs what when and based on which config values. I know nix store sign but e.g. not how I can sign after a build.
^ misunderstood the question which is looking for non-technical reasons.
Please keep them coming; all these stories are super valuable. I cannot promise you to fix everything, but I can already see a few low-hanging fruits in there.
I wrote a discourse post about such an experience here:
The main motive I hear in the stories here - regarding the lack of decision making regarding significant changes, reminds me of another thread and discussion I initiated in the past, that may be of interest:
I wanted something like this nixos-install: ask which admin account to set password for by misuzu · Pull Request #124602 · NixOS/nixpkgs · GitHub to be implemented for more user-friendly on-boarding. However, after a year, I no longer felt inclined to be invested in it.
I have had trouble figuring out where to make particular changes in both the Haskell and emacs parts of nixpkgs. Both involve generating nix from package definitions in some other location (i.e. hackage and melpa), so figuring out where fixes go isn’t as obvious as searching for packageName/default.nix in the nixpkgs repo. In the emacs case, it’s even trickier because the separate emacs-overlay repo is what I mostly interact with, but many fixes have to go upstream into nixpkgs.
To be clear, I’m very grateful for both both of these areas of the ecosystem, and I think their maintainers do a great job. They have made their maintenance jobs viable by improving efficiency. I mention them because I’m familiar with them (because I use them, because they’re great), and they are examples of how it can be hard to navigate the involved source trees. There are various ways of making this easier, but I lean towards producing and maintaining cookbook style documentation (which may exist for both Haskell and emacs at this point!) with entries like, “If you want to add a package…”, “If you need to change the dependencies of a package…”, and “If you want to patch a package before building it…”.
Not exactly an example of where I got stuck, but more a case of where i think Nix is stuck: flakes.
With the proliferation of various flakes-first introductions and handbooks its becoming more confusing for new users. When someone new reaches out for help and is met with a range of amswers from “Just use flakes” to “Well actually, they’re.experimental and have problems” it only hurts the project as a whole.
Stabilising flakes or abandoning flakes altogether: i think we need to pick one and get it over with, its been dragging on for too long.
When it comes to nixpkgs, the recurring issue is informality:
The struggle of now knowing who runs and maintains the automatic adding of people to the Nixpkgs maintainers team, or the person responsible not responding: Resend missed Nixpkgs Maintainers organization invites · Issue #234293 · NixOS/nixpkgs · GitHub
For now I defaulted to PMing Eelco to ask about it very directly to fix the above issue, but that’s not great
I’ve never considered myself “stuck” within the Nix ecosystem, thanks to many kind strangers and a few patient individuals that answered my many questions. However, there are a bunch of things that I’ve seen people around me get stuck.
Flakes
I’ve found the documentation around flakes to be inadequate and inconsistent. Although experimental, they are at a rate of very wide adoption yet there is no actual, clear, introduction to flakes that bisects the structure and purposes of flakes in a way people can understand or/and criticize.
Lack of documentation/guidelines
Think this is generally the most repeated point across the Nix users. The documentation seems to expect you to know what exactly you are doing, while you are reading it precisely because you don’t. When contributing to an official project, you are expected to know a set of rules which are never explicitly clarified. As examples, I would like to provide instances where I’ve committed to nixpkgs and maintainers who reviewed my PRs have given me conflicting instructions. Or the very recent mainProgram change, where it was apparently meant to be set but discouraged until the very end when the change has finally been made. I also find the contributing guidelines for nixpkgs to be lackluster at best. As someone who has barely ever worked with git before committing to nixpkgs, I’ve found it relatively cryptic to decide what was correct and what was not. I thank to the maintainers who assisted me with patience along the way.
Scattered documentation
This is more of a subsection to my second point, but I still do think this is prominent. The documentation is way to scattered across hundreds of sources that consist of manuals, unofficial wikis, collection of tips and tricks on gists/repositories and personal blogs as well as Github issues on various repositories.
Maintainership
I have no intention to disrespect people who are brave enough to maintain packages. However, it seems to be a reoccurring theme that maintainers suddenly drop any and all interest in a certain package without any sign of communication, leading to a situation with zero communication and also zero progress. There is also no procedure to when this kind of thing occurs. What do we do if a package maintainer is MIA? Nobody seems to know.
As an example, I’d like to provide this PR to bump nuclear music player where I’m missing a review from the old maintainer, who has gone radio silent entirely. The original package has been bumped 3 times since the PR has been made.
I’m pretty sure I’ve repeated some point that have been stated many times above, but those are the things I would like to point a finger at when working with the Nix ecosystem. It’s usually a good environment, at least for my use cases, but it tends to be very tedious for seemily random reasons at times, which turn out to be lacking documentation or communication.
It’s hard to get ‘stuck’ in Nixos. It is more of a labyrinth, which engenders a feeling of being lost.
Really there should be various levels of Nixos: initiate, basic, intermediate, advanced, and each level should have a self-contained lab with problems to solve. Once you graduate you get a key to pass to the next level. When you complete you can join the Nixosphere…
I am kidding, a bit, maybe…
Specific pain points:
Flakes - it feels like asking a child to choose a parent in a divorce
Permutations - there are infinite permutations. It would be easier if the ‘management’ just laid down the law. The sophisticates should really have their own space for discourse, because for the less advanced, we want an alternative to (Debian, Ubuntu, Fedora, et al), rather than a Space Lab experience.
I’ll put it another way: I have 3 pcs (very modest); I’d gladly
have a working system in Nixos on 1 (or two) of them, and use the other PC to muck around…
But maybe us DUFs are in the wrong place…
What Nixos should do is when people download the OS, catch them and do a study. Follow 500 people and see how they fare
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.
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.
The official docs won’t introduce Flakes before it’s stable, so I wrote a little book for beginners for this:
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 think it would be nice to have a nix book like the official rust book.