33afbf39f6
checkInputs used to be added to nativeBuildInputs. Now we have nativeCheckInputs to do that instead. Doing this treewide change allows to keep hashes identical to before the introduction of nativeCheckInputs.
46 lines
1.7 KiB
Nix
46 lines
1.7 KiB
Nix
{ lib
|
|
, buildPythonPackage
|
|
, fetchPypi
|
|
, nose
|
|
}:
|
|
|
|
buildPythonPackage rec {
|
|
pname = "yapf";
|
|
version = "0.32.0";
|
|
|
|
src = fetchPypi {
|
|
inherit pname version;
|
|
hash = "sha256-o/UIXTfvfj4ATEup+bPkDFT/GQHNER8FFFrjE6fGfRs=";
|
|
};
|
|
|
|
nativeCheckInputs = [
|
|
nose
|
|
];
|
|
|
|
meta = with lib; {
|
|
homepage = "https://github.com/google/yapf";
|
|
description = "Yet Another Python Formatter";
|
|
longDescription = ''
|
|
Most of the current formatters for Python --- e.g., autopep8, and pep8ify
|
|
--- are made to remove lint errors from code. This has some obvious
|
|
limitations. For instance, code that conforms to the PEP 8 guidelines may
|
|
not be reformatted. But it doesn't mean that the code looks good.
|
|
|
|
YAPF takes a different approach. It's based off of 'clang-format',
|
|
developed by Daniel Jasper. In essence, the algorithm takes the code and
|
|
reformats it to the best formatting that conforms to the style guide, even
|
|
if the original code didn't violate the style guide. The idea is also
|
|
similar to the 'gofmt' tool for the Go programming language: end all holy
|
|
wars about formatting - if the whole codebase of a project is simply piped
|
|
through YAPF whenever modifications are made, the style remains consistent
|
|
throughout the project and there's no point arguing about style in every
|
|
code review.
|
|
|
|
The ultimate goal is that the code YAPF produces is as good as the code
|
|
that a programmer would write if they were following the style guide. It
|
|
takes away some of the drudgery of maintaining your code.
|
|
'';
|
|
license = licenses.asl20;
|
|
maintainers = with maintainers; [ AndersonTorres siddharthist ];
|
|
};
|
|
}
|