free counter

Creating a PR to Nixpkgs

Rust-analyzer was updated recently to raised support proc macros when focusing on nightly rust versions.I needed to utilize this change immediately but since i have use NixOS I needed the nix pkg repo to update its version of rust-analyzer, therefore i may use it properly.

Because the version in Nixpkgs was outdated I decided it had been time I finally figure out how to create a PR back again to Nixpkgs. Just what exactly follows are my rough ramblings of the procedure.Some of that is rust-analyzer/rust specific, some will undoubtedly be nix-build issues generally, and some will undoubtedly be Nixpkgs PRs generally.

For reference this is actually the PR I made.

Making the branch

The standard steps when focusing on an open source project still apply

  • Fork the GitHub repo into your account
  • Clone the fork locally

For nix among the first “weird” steps would be to try to browse the commit you are using locally with the next


$ nixos-version --hash


$ git checkout 2b0dd45aca6a260762395ca2e94beab247f455a7

$ git checkout -b 'bump/rust-analyzer'

In this manner your neighborhood nix build cache is really as up-to-date as you possibly can.

Changing the nix file

This part will change based on the package if a change is really a version update just like the one I made the steps are roughly the next.

  • Update any version/rev variable to function as desired value
  • change any sha variables to pkgs.lib.fakeSha256; or simply 00000000000000000000000.
    • This can cause the build to fail but will print the proper SHA value.
    • You can find “better” methods for getting the proper SHA, but that is pretty brain-dead, therefore i usually go this route

Once those steps are done, you can test building the package. For rust-analyzer, that is done by running the next in the main of the nixpkg repo


$ nix-build -A rust-analyzer

This can build rust-analyzer and sym-link the output to ./result, so for my case I could run


$ ./result/bin/rust-analyzer --version

rust-analyzer 2022-08-01

Testing the build

While just running nix-build may be fine, some pkgs have automated tests. While they’ll be run in CI its good practice to perform them locally.

For rust-analyzer there’s this test-file that uses neovim to verify the LSP is running needlessly to say.

To perform this test I could run


$ nix-build -A rust-analyzer-unwrapped.tests.neovim-lsp

Because of this case if the ./result file is empty it worked needlessly to say.


nixpkgs-review is really a very handy tool to create a nixpkg pr and make certain all deps of a big change still build properly.

To perform it while developing it is possible to run

this can build all changes then provide you with a nix-shell to try out all of the builds

If your changes are commited you can even run


$ nixpkgs-review rev HEAD

For exactly the same effect.

Make the PR!

Execute a double check on the contributing README and the submitting changes wiki pages to ensure you followed any extra steps.

Now you’re good to submit the PR! Study the PR template as soon as your PR has been submitted a bot will run tests and assign the correct reviews.

Handling feedback

One slightly weird rule is if you need to update the PR after pushing you ought not add more commits.

To take care of this you may make a fresh commit with the changes then run


$ git rebase -i HEAD~2 # the quantity 2 here assumes you merely had one commit. In case you have more do 1+(num commits)

# in the interactive rebase window change all however the top `pick` to `s` for squash

# this can squash all commits into one

$ git push --force

You have finally joined the ranks of thankless open source developers! Feel absolve to benefit from the dopamine of the PR being merged.

Read More

Related Articles

Leave a Reply

Your email address will not be published.

Back to top button

Adblock Detected

Please consider supporting us by disabling your ad blocker