Unwritten style guides should be written
Nixpkgs has a collection of style guidelines for writing derivations listed in the [`CONTRIBUTING.md`](https://github.com/NixOS/nixpkgs/blob/674c6976c9a7bbfea0ec1f2ee80449b790f99132/CONTRIBUTING.md) and [`pkgs/README.md`](https://github.com/NixOS/nixpkgs/blob/674c6976c9a7bbfea0ec1f2ee80449b790f99132/pkgs/README.md) files. However, these guidelines are far from complete. As a result, **Nixpkgs reviewers often take it upon themselves to request changes to comply with their (unwritten, personal) style guides.** These suggestions are frustrating for PR authors for several reasons: 1. It's impossible to write a PR that complies with these suggestions before receiving a review, because they're not written down anywhere. Some suggestions come from third-party tools like [`nixpkgs-hammering`](https://github.com/jtojnar/nixpkgs-hammering) which are not mentioned anywhere in the contribution guide, effectively circumventing the actual Nixpkgs style guidelines. 2. The suggestions are frequently given to version bump PRs which do not touch the code that the suggestion applies to. Simon Tatham describes this as "The Ransom Note" in his ["Code Review Antipatterns"](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/) article: "This particular patch seems *especially* important to the developer who submitted it. [...] But this patch isn’t especially vital to you – so you’re in a position of power! Now you can hold the change they need hostage until they do lots
Posted by 9999years on Mar 4, 2025, 7:06 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.2,000 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
Unwritten style guides should be written
Nixpkgs has a collection of style guidelines for writing derivations listed in the [`CONTRIBUTING.md`](https://github.com/NixOS/nixpkgs/blob/674c6976c9a7bbfea0ec1f2ee80449b790f99132/CONTRIBUTING.md) and [`pkgs/README.md`](https://github.com/NixOS/nixpkgs/blob/674c6976c9a7bbfea0ec1f2ee80449b790f99132/pkgs/README.md) files. However, these guidelines are far from complete. As a result, **Nixpkgs reviewers often take it upon themselves to request changes to comply with their (unwritten, personal) style guides.** These suggestions are frustrating for PR authors for several reasons: 1. It's impossible to write a PR that complies with these suggestions before receiving a review, because they're not written down anywhere. Some suggestions come from third-party tools like [`nixpkgs-hammering`](https://github.com/jtojnar/nixpkgs-hammering) which are not mentioned anywhere in the contribution guide, effectively circumventing the actual Nixpkgs style guidelines. 2. The suggestions are frequently given to version bump PRs which do not touch the code that the suggestion applies to. Simon Tatham describes this as "The Ransom Note" in his ["Code Review Antipatterns"](https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/code-review-antipatterns/) article: "This particular patch seems *especially* important to the developer who submitted it. [...] But this patch isn’t especially vital to you – so you’re in a position of power! Now you can hold the change they need hostage until they do lots
Comments (0)
No comments yet. Start the discussion.