6 ms·

Making a PR to Nixpkgs

43 points by jrmurray 4y ago

gigatexal 4y ago
I’d do a git commit —amend instead of a rebase to keep the number of commits to 1
- e3bc54b2 4y ago
  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.
  - saagarjha 4y ago
    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.
    - alexchamberlain 4y ago
      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.
  - johnny22 4y ago
    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.
- meibo 4y ago
  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.
  - Avamander 4y ago
    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.
- jrmurray 4y ago
  Not sure why I always forget amend exists. That is much cleaner
yewenjie 4y ago
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.
- achooie 4y ago
  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.
- jrmurray 4y ago
  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.
  - rgoulter 4y ago
    From the 2022 Nix Survey's results: https://discourse.nixos.org/t/2022-nix-survey-results/18983 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-stream/20351 https://discourse.nixos.org/t/summer-of-nix-documentation-st...
  - WhyNotHugo 4y ago
    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.
coldblues 4y ago
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.
- jrmurray 4y ago
  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...
- Kaze404 4y ago
  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.
- WhyNotHugo 4y ago
  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).
  - rgoulter 4y ago
    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.

43 points by jrmurray 4y ago

gigatexal 4y ago

I’d do a git commit —amend instead of a rebase to keep the number of commits to 1

e3bc54b2 4y ago
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.
- saagarjha 4y ago
  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.
  - alexchamberlain 4y ago
    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.
- johnny22 4y ago
  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.
meibo 4y ago
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.
- Avamander 4y ago
  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.
jrmurray 4y ago
Not sure why I always forget amend exists. That is much cleaner

yewenjie 4y ago

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.

achooie 4y ago
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.
jrmurray 4y ago
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.
- rgoulter 4y ago
  From the 2022 Nix Survey's results: https://discourse.nixos.org/t/2022-nix-survey-results/18983 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-stream/20351 https://discourse.nixos.org/t/summer-of-nix-documentation-st...
- WhyNotHugo 4y ago
  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.

coldblues 4y ago

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.

jrmurray 4y ago
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...
Kaze404 4y ago
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.
WhyNotHugo 4y ago
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).
- rgoulter 4y ago
  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.