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:
5 Likes
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
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
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.
31 Likes
When it comes to nixpkgs, the recurring issue is informality:
- 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.
- 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
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
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.
8 Likes
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…
6 Likes
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
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:
11 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