python3Packages.lintrunner: init at 0.12.7

[PrestonHager]

Based on https://github.com/suo/lintrunner upstream. Package is listed in PyPI already at https://pypi.org/project/lintrunner/.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[natsukium]

I think this tool is an application but not a library.
If so, please use buildPythonApplication and move it to pkgs/by-name/li/lintrunner instead.

[PrestonHager]

It is an application, I've used buildPythonApplication instead of buildPythonPackage. The typical way to install the application is via pip, should the package then be referenced/placed in the python top-level packages? This way it can be installed using python3Packages.lintrunner instead of the package name lintrunner, or is this bad practice?

[natsukium]

Could you add tests with pythonImportsCheck and pytestCheckHook?
https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/python.section.md#testing-python-packages-testing-python-packages

[PrestonHager]

Since it's an application, there's no imports to check with python. It's written in rust, should I run cargo test under the package to ensure tests? Not quite the same as testing the installed binary, but testing the application code functionality itself.

[PrestonHager]

@natsukium I was able to make most of the changes you suggested, I have a couple of questions with regards to some changes. I left comments under each suggestion, but here they are below for completeness:

1. It is an application, I've used buildPythonApplication instead of buildPythonPackage. The typical way to install the application is via pip, should the package then be referenced/placed in the python top-level packages? This way it can be installed using python3Packages.lintrunner instead of the package name lintrunner, or is this bad practice?
2. I'd like to use patches instead of a fork of the repository, but I could not get a git diff --cached > file.patch to work locally, probably doing something wrong. I tried using patches = [ file.patch ]; and cargoPatches = [ file.patch ]; but neither seemed to change the contents of the source directory. I also noticed that this would be creating a new file (Cargo.lock) rather than changing the contents of a file.
3. Since it's an application, there's no imports to check with python. It's written in rust, should I run cargo test under the package to ensure tests? Not quite the same as testing the installed binary, but testing the application code functionality itself.
4. I left an issue in the upstream repository, #84. If I were to guess, it's meant to be MIT and the other one is from Cargo doing something. In the meantime, is there a dual license option we can do to specify both licenses for the nix package?

Thank you for the review and all the help!

[FliegendeWurst]

Suggested change

	version = "0.12.7";
	version = "0.12.7-unstable-2025-07-03";

Since you aren't using the tagged release we should add the commit date here. Also please put a comment why the tagged release is not used. (And meta.changelog needs to be adjusted)