Where did you get stuck in the Nix ecosystem? Tell me your story

Development
1

Hey,

I’m looking for examples of where you got stuck when being involved in the Nix ecosystem.

Something you wanted to get done, had the energy to do, and then it didn’t happen because of X. Where X can be anything non-technical. For example, you didn’t know who to ask. Or implemented something and the PR got stuck with nobody making a decision. Some doc was missing. Somebody was hostile to you and you got tired of it. Anything non-technical.

I want to hear your stories.

If that story puts someone in a bad light, please send those stories directly to me and I will filter them.

By taking the time to reply here, you will be helping improve how we function together, on the cultural, leadership, and organizational levels. These data points are super valuable for some of the ongoing discussions we are having both inside of the NixOS Foundation and also in other places in the community.

29 Likes
2

I’ve was trying to introduce GitHub - fzakaria/shrinkwrap: A tool that embosses the needed dependencies on the top level executable into Nixpkgs (with the help of others such as @tomberek ) – some high-level discussions Speed up application startup by using `ld.so.cache` by winterqt · Pull Request #207061 · NixOS/nixpkgs · GitHub

Shrinkwrap or GitHub - fzakaria/nix-harden-needed: Bubble up the correct paths to your shared object libraries in Nix was integrated into Guix and Spack already.

The bureaucracy burden was too overwhelming so I stopped pushing on it.

22 Likes
3

No exact one time, and not necessarily using NixOS but I’ve been tripped up pretty regularly writing about and making videos about NixOS when it comes time to give a concrete name to something in the moment. For example, what is the correct name for a file that has an arglist at the top eg. {pkgs, stdenv, ...}: There are a maddening number of names used in various documentation to refer to these things, like “package” (think callPackage), package definition, expression file, and others. But they aren’t even always packages or package definitions because not all of them define a derivation. Expression files is just something I may have even made up. They aren’t modules. Etc. I recognize that once they are parsed they are pretty much just functions but this doesn’t really help someone who is very new.

Anyway, I’ve found it difficult to explain things to first timers when even somebody like me after a year or so is still fumbling for terms of concrete things.

16 Likes
4

When I started creating the Nixpkgs Architecture Team, I didn’t really know how to create new teams and repositories in the official NixOS GitHub organization, so I created an entirely separate Nixpkgs Architecture GitHub organization where I wouldn’t have to worry about missing permissions.

I also asked @grahamc multiple times whether I could upload meetings to the official NixOS Foundation YouTube channel, but I never get a proper reply, so I created a separate YouTube channel instead. In retrospect, this wouldn’t have been a good fit for the official YouTube channel anyway and I should’ve been told No, but it delayed me with proceeding to create the team.

12 Likes
5

Whenever I dive into the mess that is nvidia (not for lack of effort on NixOS maintainers’ side, nvidia is just nvidia) I’m a bit stuck between those two. Smaller things like version bumps on stable tend to be met with a resounding silence, and for larger things pings don’t get responses or at best an “I don’t know either”.

It’s a shame, I really think we need a latestStableForNvidia like zfs has, and it would be cool to get a conclusive answer about whether we should work around this bug. Also someone needs to have a hard look at the nixos-hardware module and the architectural mess it causes all over the repository.

Sadly I don’t even know where to start. There’s zero documentation on maintainer team structure, who and how to contact about module design, etc. Just some git formalities and maintainer tags pointing to people who are either absent or too busy.

The other issue is that even when I do dig through GitHub and find someone, nobody seems “in charge” enough to have an opinion on whether my suggestions are insane, useful, or something in between that needs more thought.

Ultimately I think this is a cultural issue, perhaps partly caused by GitHub. NixOS seems to be maintained primarily by drive-by contributors, which results in rather limited communication over a longer time period.

Either way, I’m just sitting on my hands ranting on discourse, I should roll up my sleeves and at least fix the wiki page on nvidia, thanks for listening.

13 Likes
6

The brief for me would likely be the bureaucracy of it all, and ultimately the power-holding individuals in the NixOS organization being unavailable/passive on improvements.

For more exact painpoints, while reviewing a refactor of buildMavenPackage I noticed an issue in how meta.platforms were defined in openjdk. So wanting to raise this issue, i found that openjdk suprisingly only has a single maintainer listed who has not been active in the openjdk codebase since 2016. While people moving on is natural and completely okay, the understanding that there currently not any one active and available maintainer listed for Java was rather worrisome.

Disucssing this on Matrix was received with several messages in the shape of “that’s not great” from influential people inside nixpkgs, but I was ultimately advised to look at picking up openjdk as a new maintainer and help refactor it.

While I definitely could, but, it left me feeling yet again like I am somehow needing to be responsible for yet another huge chunk of nixpkgs. And whatever refactors I would end up creating, I fear that the PR of that would end up left open. As ultimately, nobody seems in charge or available.

Further issues would include the withdrawn status of the Nix Flakes RFC without any way for the community to get it pushed past its “forever experimental” stage that it has been permanently put in. Other issues are PRs in nixpkgs I have watched, for, a, long, time.

23 Likes
7

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.

15 Likes
8

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.

17 Likes
9

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.

1 Like
10

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.

3 Likes
11

I wrote a discourse post about such an experience here:

1 Like
12

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:

4 Likes
13

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.

2 Likes
14

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…”.

5 Likes
15

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.

30 Likes
16

When it comes to nixpkgs, the recurring issue is informality:

  1. Lack of written and/or automated guidelines. Best practices are constantly changing and the only way to discover them is to read lots of pull request reviews or submit a pull request and receive the same repetitive reviews. This is a waste of everybody’s time and highly demotivating.
  2. Lack of committer hierarchy. Oftentimes committers will be uncertain about whether they have the authority to make a change and wont know who to ask. Without a hierarchy even committers have no way to escalate an issue and such pull requests either go stale or some committer takes the initiative to merge it and takes the chance of being rebuked. (I see this happen even on changes only affecting an individual package, so the RFC process is not the answer.)
14 Likes
17

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

3 Likes
18

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

8 Likes
19

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…

5 Likes
20

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…

1 Like