pythonPackages.dkimpy: init -> 0.6.1 #25021
Conversation
| makeWrapper "$out/libexec/dkimsign.py" $out/bin/dkimsign | ||
| makeWrapper "$out/libexec/arcverify.py" $out/bin/arcverify | ||
| makeWrapper "$out/libexec/arcsign.py" $out/bin/arcsign | ||
| makeWrapper "$out/libexec/dknewkey.py" $out/bin/dknewkey |
There was a problem hiding this comment.
The packages for other distributions don't seem to have this renaming stuff (neither the included .spec in upstream nor the one one ArchLinux AUR). I think it would be better to not derivate from upstream here unless absolutely necessary.
There was a problem hiding this comment.
The reason I did this, is that the man pages that are included do not have the .py in their invocation. So my thought was that invoking 'man dkimsign' would be more logical if the command and the man page naming scheme were synchronised. Obviously, I have no preference either way - but to a new user it might make more sense.
There was a problem hiding this comment.
Ok thanks for the explanation, that makes sense, let's leave it this way then.
| @@ -0,0 +1,44 @@ | |||
| { stdenv, pythonPackages, fetchurl, openssl, makeWrapper }: | |||
There was a problem hiding this comment.
It would be better to depend on pytest explictly here instead of using pythonPackages. The callPackage from python-packages.nix does not explictly define pythonPackages, so this pythonPackages here might be a for a different python version than what buildPythonApplication expects.
There was a problem hiding this comment.
I don't really understand what you mean precisely. I included pythonPackages in line 3, using: "with pythonPackages;" - but that could be the wrong one, you think? Are you suggesting I should add pytest to line 1, or change pythonPackages in line 1 or line 3 to pkgs.pythonPackages?
There was a problem hiding this comment.
Add pytest to line 1 and remove all usages of pythonPackages.
There was a problem hiding this comment.
@bennofs pytest is only accessible via a package set like pythonPackages for python applications living outside of pythonPackages. I would say the current approach chosen here is ok and does not deviate from other python applications.
There was a problem hiding this comment.
in the case of packages called via python+packages.nix it should really not have pythonPackages as parameter
There was a problem hiding this comment.
@Mic92 the package is not defined outside of pythonPackages though, it is callPackaged from python-packages.nix.
There was a problem hiding this comment.
callPackage from python-packages.nix to an expression outside /development/python-modules is wrong. If this is an application then it should be called straight from all-packages.nix (in which case we DO pass pythonPackages)
There was a problem hiding this comment.
@FRidh: my 'problem' was that the package is both: a Python dkim library by origin, but a set of very useful tools with man pages and all as well. I could move this to development/python-modules, so other Python applications can easily use it? While retaining the fact that it also installs some useful executables.
There was a problem hiding this comment.
@leenaars yes, if it is both an application and library, move it to python-modules and add an top-level alias to all-packages.nix from pythonPackages.
|
Pulled buildInputs and propagatedBuildInputs together, otherwise await feedback. |
| @@ -0,0 +1,44 @@ | |||
| { stdenv, pythonPackages, fetchurl, openssl, makeWrapper }: | |||
There was a problem hiding this comment.
in the case of packages called via python+packages.nix it should really not have pythonPackages as parameter
Motivation for this change
A useful set of tools and underlying library for working with DKIM and ARC (IETF standards for email authenticity).
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)