Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

diff_cover: init at 1.0.2 #33715

Merged
merged 3 commits into from Jan 19, 2018
Merged

diff_cover: init at 1.0.2 #33715

merged 3 commits into from Jan 19, 2018

Conversation

dzabraev
Copy link
Contributor

@dzabraev dzabraev commented Jan 10, 2018

Motivation for this change

new packages for diff_cover, pydocstyle, jinja2_pluralize

diff_cover depends on pydocstyle, jinja2_pluralize

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@dzabraev dzabraev requested a review from FRidh as a code owner January 10, 2018 19:04
@dzabraev dzabraev changed the title Diff cover diff_cover: init at 1.0.2 Jan 10, 2018
@teto
Copy link
Member

teto commented Jan 11, 2018

I've also packaged pydocstyle in #31180. Yours seem to enable tests but always including configparser might fail I believe.

pname = "diff_cover";
version = "1.0.2";

LC_ALL = "en_US.UTF-8";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is only needed for the tests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it is. Without setting this variable tests will fail. Where should I put this variable definition?

Without this variable tests fail, if this variable will be visible only during tests execution,
runtime execution may fail too without LC_ALL.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The env var can be set in the preCheck hook. This env var won't be set during runtime anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This package supply some executable files. If I wrap this executables with makeWrapper and set LC_ALL in wrapper?


propagatedBuildInputs = [ jinja2 jinja2_pluralize pygments six inflect ];

buildInputs = [ mock nose coverage pycodestyle flake8 pyflakes pylint pydocstyle git ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test requirements go into checkInputs


LC_ALL = "en_US.UTF-8";

src = fetchFromGitHub {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any reason for not using PyPI?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Package from PyPi fails tests when build is doing in sandbox. I told about that to author of diff-cover. He fixed that bug.

Here this conversation about this bug.
Bachmann1234/diff_cover#72

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work! If it is a patch on top of a release, then we fetch the patch with fetchpatch instead and add it to patches.

src = fetchFromGitHub {
owner = "Bachmann1234";
repo = "diff-cover";
rev = "85c30959c8ed2aa3848f400095a2418f15bb7777";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can refer to a tag here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I refer to the last tag, tests will fail. Maybe it is better refer to this commit?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

six, inflect, mock, nose, coverage, pycodestyle, flake8, pyflakes, git,
pylint, pydocstyle }:

buildPythonPackage rec {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this tool need to access Python modules of the environment it is used in, or is it just an external tool?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

( Maybe I didn't understand what you ask. I'm learning english ... :) )
This tool is not supposed to provide python modules for users.
It provide two execution files: diff-cover, diff-quality

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This tool doesn't need access to environment where it is used in.


propagatedBuildInputs = [ snowballstemmer configparser ];

buildInputs = [ pytest pytestpep8 mock pathlib ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checkInputs

@@ -22660,6 +22660,13 @@ EOF
voluptuous = callPackage ../development/python-modules/voluptuous { };

pysigset = callPackage ../development/python-modules/pysigset { };

jinja2_pluralize = callPackage ../development/python-modules/jinja2_pluralize { };
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Attributes are roughly organized. Surely you can find a better place for these.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is criteria of "better place" ?
I don't understand why this place is bad.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attributes should be ordered by name.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be order by derivation name or by attribute name?
I still does not understand what you want because the attribute set doesn't have lexicographical order...

If i put this attribute near line 9493 (near jinja package) will it be ok?

@dzabraev
Copy link
Contributor Author

dzabraev commented Jan 17, 2018

@FRidh , why didnt you merge this request? I did all changes that you required.

@FRidh
Copy link
Member

FRidh commented Jan 18, 2018

@dzabraev

  • Without an explicit mention I am not aware of the changes you made;
  • Lack of time.

@FRidh
Copy link
Member

FRidh commented Jan 18, 2018

Please squash the commits so there is a commit per expression.

@dzabraev
Copy link
Contributor Author

@FRidh I have done your requirements.

@FRidh FRidh merged commit 018a210 into NixOS:master Jan 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants