vulnix: init at 1.2.2 #23863
vulnix: init at 1.2.2 #23863
Conversation
|
|
||
| rec { | ||
|
|
||
| BTrees = buildPythonPackage { |
There was a problem hiding this comment.
Is this autogenerated? If so, I'd put in a comment explaining how to update it.
pkgs/top-level/python-packages.nix
Outdated
| @@ -32014,6 +32014,8 @@ EOF | |||
| }; | |||
| }; | |||
|
|
|||
| vulnix = callPackage ../tools/security/vulnix { }; | |||
There was a problem hiding this comment.
vulnix is a tool right that one doesn't use to develop with a certain Python env (like e.g. pip or pytest), right? In that case it shouldn't be called from python-packages.nix but elsewhere. In that case the expression should have as argument python or pythonPackages instead of the individual Python packages/functions.
There was a problem hiding this comment.
Okay, where to put it then?
|
|
||
|
|
||
|
|
||
| lxml = buildPythonPackage { |
There was a problem hiding this comment.
what is the reason for using this specific version instead of the one we have in python-packages.nix?
There was a problem hiding this comment.
Same goes for the other packages as well.
There was a problem hiding this comment.
We have the habit to pin down versions of dependent packages.
setup.py:
install_requires=[
'click==6.6',
'colorama==0.3.7',
'lxml==3.7.0',
'pyyaml==3.11',
'requests==2.10.0',
'ZODB==5.1.1',
],
If there are recommendations to override those in setup.py, I'd like to know them. I am really uncertain about the pattern of dependence on external packages vs. nixpkgs' ones.
There was a problem hiding this comment.
In my opinion its bad practice to pin versions exactly. Assuming dependencies use semantic versioning there is no need to pin exact versions. Unfortunately its a bit tedious to pin only to major or minor releases.
In any case, when we encounter packages that pin their dependencies even though there is no need for it, we patch those entries.
E.g.
postPatch = ''
substituteInPlace setup.py --replace "sympy==0.7.6" "sympy"
'';
There was a problem hiding this comment.
At the same time, managing versions in python-packages.nix is tedious, but it seems like we should address that more broadly than an individual package. If you absolutely must use a specific version, perhaps do something like pythonPackages.overrideDerivation (_: src = fetchPypi ...)? That way you can at least share any nix-specific patches people have applied to the other version, and we share more code.
|
I replaced most new python packages by packages already present in nixpkgs. Since tests are executed by vulnix, this should be a safe operation. ZODB in nixpkgs can be also upgraded, but I have not done this so far. |
|
could you squash all except "pythonPackages.BTrees: 4.1.4 -> 4.3.1" |
|
squashed the commits. |
Motivation for this change
Vulnix is a tool made for Nix/NixOS, so I guess it should be part of nixpkgs. 馃榿 Cheers @Mic92 for offering the PR review
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)