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

vint: init at 0.3.11 #22497

Merged
merged 1 commit into from Feb 21, 2017
Merged

vint: init at 0.3.11 #22497

merged 1 commit into from Feb 21, 2017

Conversation

andsild
Copy link
Contributor

@andsild andsild commented Feb 6, 2017

Motivation for this change

New package

I tested using python35 and python36: nix-env -f $NIXPKGS --option build-use-chroot true --option use-binary-caches false -i vim-vint, nix-shell -I nixpkgs=. --pure -p vim-vint, and nix-build -A vim-vint && ./result/bin/vint

I made sure that the resulting executable worked on vimrc-files, e.g. vint ~/.vimrc --color

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
    • Linux
  • 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.

@andsild
Copy link
Contributor Author

andsild commented Feb 6, 2017

For now I am not able to reproduce the travis error locally. Seems to be OSX related, or just pathlib not supporting long filenames. If anyone has feedback that would be great.

Meanwhile, I'll see if I can be creative enough to think of another solution..

@joachifm
Copy link
Contributor

joachifm commented Feb 6, 2017

Note that if you're using nix-daemon, passing build-use-sandbox to nix-env probably won't do what you expect.

@@ -26314,6 +26314,25 @@ in {
};
};

vim-vint = 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.

The linter looks like an executable not a python library to me. We usually do not put applications into python-packages.nix but into a dedicate file, which is referenced in all-packages.nix.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Okay. I thought it made sense, I also saw for example pylint being in python-packages.nix. But since the resulting binary isn't strictly related to python, I see why it should be a dedicated package. I can try that 👍

@Mic92
Copy link
Member

Mic92 commented Feb 6, 2017

It looks like the temporary path chosen to build this library adds a prefix, which exceeds the character limit of OSX for unix socket paths. One option could be to ignore this test conditionally on OSX by renaming the test methods: ex.: test_is_socket_true -> skip_test_is_socket_true.

@andsild
Copy link
Contributor Author

andsild commented Feb 11, 2017

@Mic92
I couldnt just rename the tests since they were not a part of the vim-vint package (unless I modified pathlib in python-packages.nix, which maybe is permissible?). So instead, I used python3 which has pathlib as part of the standard library.

Now I got some new errors for OSX: SSL: CERTIFICATE_VERIFY_FAILED. This seems to be related to NixOS/nix#921. I amended this by putting in the dependencies as buildInputs.

sha256 = "cda7090116b3aea12bdfe8ed44e71ead739df4e7e0ad24e27bb87754dedb613b";
};

# OSX keeps getting error: `Download error on https://pypi.python.org/simple/coverage: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some packages may not be found!`
Copy link
Member

Choose a reason for hiding this comment

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

pip automatically attempts to download dependencies but we've blocked that. You should provide the dependencies via nix.

};

# OSX keeps getting error: `Download error on https://pypi.python.org/simple/coverage: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:720) -- Some packages may not be found!`
# To amend this, we use nix for the packages (instead of letting setup.py fetch them).
Copy link
Member

Choose a reason for hiding this comment

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

That's indeed how we do it. No need to put it here :)

patchPhase = stdenv.lib.optionalString stdenv.isDarwin ''
substituteInPlace setup.py --replace "load_requires_from_file('test-requirements.txt')" "[]"
'';
buildInputs = with python3Packages; stdenv.lib.optionals stdenv.isDarwin [ coverage pytest pytestcov ];
Copy link
Member

Choose a reason for hiding this comment

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

why are these test inputs only needed for Darwin? That seems incorrect to me, the tests should run on any platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had it off for all, but in travis the OSX tests failed.

I can remove the stdenv.lib.optionalString anyway, since the linux builds also should run the tests using the libraries.

Thanks for the feedback, I'll look into all the comments.

Copy link
Contributor Author

@andsild andsild Feb 13, 2017

Choose a reason for hiding this comment

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

An even better solution: realize that the pypi version of this pacakge (vim-vint) doesn't ship with tests, so I can just skip the buildinputs anyway, for as long as I do the patchPhase. Waiting for travis to verify that it still works...

I'm not sure, is it better to get this version of vim-vint from github, where they ship with a test folder containing unit tests?

@@ -0,0 +1,28 @@
{ lib, pkgs, python3Packages, stdenv }:
Copy link
Member

Choose a reason for hiding this comment

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

never pass in pkgs, just pass in fetchurl.

@FRidh
Copy link
Member

FRidh commented Feb 14, 2017

Packages without tests can fail to build/work without us knowing why or that it even happened. It's up to you as maintainer to choose. We prefer to have tests.

@andsild
Copy link
Contributor Author

andsild commented Feb 14, 2017

@FRidh I agree, its nice with tests. I'll change it to be github-based later today.

My reasoning to choose pypi was that its the same store/mirror as what pip uses. Therefore, if anyone had a problem with this nix package, they wouldnt have to speculate on differences between github-version and pypi version of vim-vint.

@andsild
Copy link
Contributor Author

andsild commented Feb 20, 2017

@FRidh I made fixes for the changes if you want to review

'';

meta = with lib; {
description = "Fast and Highly Extensible Vim script Language Lint implemented by Python.";
Copy link
Member

Choose a reason for hiding this comment

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

Remove dot at the end please.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done!

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

6 participants