Making a PR to Nixpkgs(johns.codes)
johns.codes
Making a PR to Nixpkgs
https://johns.codes/blog/updating-a-package-in-nixpkgs
21 comments
While I really love nix and nixos, I must say that Nixpkgs development is just out of control. There are over 5k issues and almost 4k PRs open. Reviewers are far fewer in number than contributors and there are multiple instances of low-quality packaging. Some features that most beginners want (for example, easily packaging nodejs programs) are still not there. Lack of standard is a heavy issue and there are many ways of doing the same.
> Lack of standard is a heavy issue and there are many ways of doing the same.
I'd partially blame the software as well. You can't standardise what doesn't want to follow standards. A lot of software or their developers work against the Nix model, some do so actively. The most visible example is the XDG-BD standard (https://wiki.archlinux.org/title/XDG_Base_Directory), but there are a bunch of other things like that which make packaging difficult.
I'd partially blame the software as well. You can't standardise what doesn't want to follow standards. A lot of software or their developers work against the Nix model, some do so actively. The most visible example is the XDG-BD standard (https://wiki.archlinux.org/title/XDG_Base_Directory), but there are a bunch of other things like that which make packaging difficult.
Yea I think the main issue holding nix back is lack of documentation/standards on how to do things.
Like the other commenter mentioned how npmlock2nix exists but it's hard to figure out that these tools exists.
Im hoping that flakes help solve alot of problems to make it easier for users to jump in. Then hopefully the documentation problem will naturally start going away as more people start using nix.
Like the other commenter mentioned how npmlock2nix exists but it's hard to figure out that these tools exists.
Im hoping that flakes help solve alot of problems to make it easier for users to jump in. Then hopefully the documentation problem will naturally start going away as more people start using nix.
From the 2022 Nix Survey's results:
https://discourse.nixos.org/t/2022-nix-survey-results/18983
The main pain points people identified:
- Getting started with Nix is hard.
- The documentation isn't great for getting started, for getting some task done, and is spread across many places.
- Debugging bad Nix code is hard.
- Contributing back to Nix is hard.
Despite the above, I think most of the respondents had just started using Nix within the last year or two.
I think some of the Summer of Nix effort is towards improving documentation. e.g. https://discourse.nixos.org/t/summer-of-nix-documentation-st...
The main pain points people identified:
- Getting started with Nix is hard.
- The documentation isn't great for getting started, for getting some task done, and is spread across many places.
- Debugging bad Nix code is hard.
- Contributing back to Nix is hard.
Despite the above, I think most of the respondents had just started using Nix within the last year or two.
I think some of the Summer of Nix effort is towards improving documentation. e.g. https://discourse.nixos.org/t/summer-of-nix-documentation-st...
Bad or missing documentation on Nix is a known issue. I think a big part of this issue is that the language itself doesn't have a mechanism to provide documentation.
Python has docstrings, Java has javadoc, Hare has haredoc, Lua has emmylua... etc. Every language has SOME WAY of leaving explanation on what a function does, and what values it takes. Nix doesn't seem to have such a thing (if it does, it's a well-kept secret!).
Functions being lazy doesn't help, since that makes it very hard for tools to provide feedback without actually executing the right codepaths. And finding the definition of a function is HARD.
Python has docstrings, Java has javadoc, Hare has haredoc, Lua has emmylua... etc. Every language has SOME WAY of leaving explanation on what a function does, and what values it takes. Nix doesn't seem to have such a thing (if it does, it's a well-kept secret!).
Functions being lazy doesn't help, since that makes it very hard for tools to provide feedback without actually executing the right codepaths. And finding the definition of a function is HARD.
It sort of does for modules [1] but not functions iirc.
[1] https://nixos.wiki/wiki/Declaration
[1] https://nixos.wiki/wiki/Declaration
I agree with what you’re saying, but I have to say that using `npmlock2nix` was really easy. Things are changing and improving all the time, which is good but also creates these sorts of problems.
NixOS is the most daunting Linux distribution ever, and all the people I know that use it are extremely smart. You need to develop a really good mental model of how this complicated web of Nix scripts works, to create packages.
Yea I will agree it's daunting. I've been using nix os for 2 years and this was my first time making a pr back.
I think using nix for personal projects helps build your mental model a lot more. Once you take the time to build a package manually alot of it clicks.
As a user of nixos/nix if you're not building packages it's great. Nixos is quite declarative for most settings. The main issue is just figuring out what options exist...
I think using nix for personal projects helps build your mental model a lot more. Once you take the time to build a package manually alot of it clicks.
As a user of nixos/nix if you're not building packages it's great. Nixos is quite declarative for most settings. The main issue is just figuring out what options exist...
It took me at least a year of using NixOS daily to be comfortable enough to even attempt packaging software. Of course I'm still learning, but once you get past the initial barrier of "what the heck is any of this even doing", it becomes a lot easier and entertaining to find out for yourself.
I think that is being developed by people who are too smart is the problem. There's no KISS. They're fine with very complicated solution, because they seem easy to them.
We not-so-smart developers tend to go for the simplest solution possible (but usually, no simpler).
We not-so-smart developers tend to go for the simplest solution possible (but usually, no simpler).
The reason it is sort of complex is simply the fact that the problem domain is complex. I don’t think there is a big deal of accidental complexity around nix, it is mostly just essential, which can’t be reduced.
The same is true of the often bashed systemd - system boot is a hard problem, it gives a correct solution over incomplete but simple ones, and thus it will be more complex. But some complexity is inherent, so we just have to deal with that. (Rust could be another example - correct manual memory management necessities some added complexity )
The same is true of the often bashed systemd - system boot is a hard problem, it gives a correct solution over incomplete but simple ones, and thus it will be more complex. But some complexity is inherent, so we just have to deal with that. (Rust could be another example - correct manual memory management necessities some added complexity )
I guess compare to some alternatives:
I believe it's not very weird if someone says "I messed up my Arch Linux installation, and so re-installed from scratch". (Although I don't think it's common for people to re-install all the time).
Or the most ubiquitous way of deploying software from one machine to another is to build a Docker/container image. i.e. to package the built binaries of executables and libraries in such a way that they can be run portably. -- Prob'ly the most common way to build Docker images is to write a Dockerfile, which is more/less a simple sequence commands to run.
I mean.. lots of stuff involving installing/distributing/configuring packages is very hard, and conventional solutions are layers of familiar beat-things-into-shape solutions, where you don't need a deep understanding of what's going on to get things done.
Some of the implementation in Nixpkgs is complicated (like lazy fixpoint stuff), but I've also seen e.g. developers not like Nix because they don't like the idea of learning the Nix language.
I believe it's not very weird if someone says "I messed up my Arch Linux installation, and so re-installed from scratch". (Although I don't think it's common for people to re-install all the time).
Or the most ubiquitous way of deploying software from one machine to another is to build a Docker/container image. i.e. to package the built binaries of executables and libraries in such a way that they can be run portably. -- Prob'ly the most common way to build Docker images is to write a Dockerfile, which is more/less a simple sequence commands to run.
I mean.. lots of stuff involving installing/distributing/configuring packages is very hard, and conventional solutions are layers of familiar beat-things-into-shape solutions, where you don't need a deep understanding of what's going on to get things done.
Some of the implementation in Nixpkgs is complicated (like lazy fixpoint stuff), but I've also seen e.g. developers not like Nix because they don't like the idea of learning the Nix language.
I’d do a git commit —amend instead of a rebase to keep the number of commits to 1
That is what I dislike about the Pull Request workflow. It encourages piling on commits, polluting commit log (not to mention useless merge commits). To this day I haven't found anything better than Gerrit for reviewing changes across iterations. I wish it makes a comeback on broader scale.
Pull requests are great, you just need to be mindful of what commits you're sending people. Every commit I put in a PR is a commit I made with intent. Just squashing them all does them a disservice.
I don't know how many times I've said that reviewing the structure of the commits is part of a PR, just like reviewing the code. It seems to be a revelation.
luckily github can just squash it for you if you choose. You don't have to have a useless merge commit. The option is right there in the dropdown. I assume gitlab as well.
Not sure why I always forget amend exists. That is much cleaner
Ideally your commits are squashed and then merged anyway, GitHub just still uses merge as a default since I assume it's the most "logical" to git newbies.
Only a polluted commit history should be squashed - bad commit messages, incorrect segmentation, fixes to earlier commits etc.
Think of it this way, if the commit works on its own it should remain as-is. If it's a hodgepodge of ten commits that inter-depend then they probably should be squashed.
Think of it this way, if the commit works on its own it should remain as-is. If it's a hodgepodge of ten commits that inter-depend then they probably should be squashed.