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

pythonPackages.dkimpy: 0.6.2 -> 0.8.1 #43219

Merged
merged 2 commits into from Jul 8, 2018
Merged

Conversation

leenaars
Copy link
Contributor

@leenaars leenaars commented Jul 8, 2018

Motivation for this change

Bumped version. Packaged dependency (authres) as separate commit.
Note that dkimpy both serves as a library and contains a set of tools.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option 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/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

@dotlambda
Copy link
Member

Please also make all changes requested in #34980.

@dotlambda
Copy link
Member

Is dkimpy both, an application and a library? If so you can keep it under pythonPackages but please reflect this in your commit message. In all-packages.nix, please use toPythonApplication.

@dotlambda
Copy link
Member

Btw, CONTRIBUTING.md tells you to use init at, not init ->

@dotlambda dotlambda changed the title (pythonPackages.)dkimpy: 0.6.2 -> 0.8.1 pythonPackages.dkimpy: 0.6.2 -> 0.8.1 Jul 8, 2018
pname = "authres";
version = "${majorversion}.${minorversion}";

src = fetchurl {
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 not to use fetchPypi?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No particular reason. This is the upstream/source. Of course pypi is mirrored, so if you want I can change.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, please do. This will facilitate (semi-)automatic upgrades.

Copy link
Member

Choose a reason for hiding this comment

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

And it will allow us to get rid of majorversion and minorversion.

majorversion = "0.6";
minorversion = "2";
majorversion = "0.8";
minorversion = "1";
in buildPythonApplication rec {
pname = "dkimpy";
version = "${majorversion}.${minorversion}";

src = fetchurl {
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 not to use fetchPypi?

};

checkInputs = [ pytest ];
propagatedBuildInputs = [ openssl dnspython ];
propagatedBuildInputs = [ openssl dnspython pynacl authres ];
Copy link
Member

Choose a reason for hiding this comment

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

openssl is not needed 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.

My assumption was that since one of the tools (dknewkey) needs an openssl binary, this would have to be part of the path - and thus be a propagated input. Is that not the case?

Copy link
Member

@dotlambda dotlambda Jul 8, 2018

Choose a reason for hiding this comment

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

If it's needed in the path, then one of the following solutions should be used:

  • Patch the path into the source code as you're doing it for dknewkey (preferred)
  • Use makeWrapper

So, if the substituteInPlace you're doing patches all places where openssl is called you should be fine and won't need openssl in *buildInputs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But isn't it more robust to make it explicit that it needs this input? I can imagine some kind of future optimisation that creates minimal chroot environments with only the declared propagatedBuildInputs... There seems no harm in not having the very smallest closure if it is clearer for the future?

Copy link
Member

@dotlambda dotlambda Jul 8, 2018

Choose a reason for hiding this comment

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

Yes, there is harm. You don't want any project using dkimpy to have openssl in its path. That should be made explicit.

Copy link
Member

Choose a reason for hiding this comment

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

propagatedBuildInputs should generally never be used. Sadly, for Python libraries there's currently no better solution.

majorversion = "0.6";
minorversion = "2";
majorversion = "0.8";
minorversion = "1";
in buildPythonApplication rec {
Copy link
Member

Choose a reason for hiding this comment

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

buildPythonPackage

@@ -615,7 +615,7 @@ with pkgs;

dgsh = callPackage ../shells/dgsh { };

dkimpy = pythonPackages.dkimpy;
dkimpy = with pythonPackages; toPythonApplication dkimpy;
Copy link
Member

Choose a reason for hiding this comment

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

👍

@dotlambda
Copy link
Member

Please still do use the pythonPackages prefix in the commit message.

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
Copy link
Member

@dotlambda dotlambda Jul 8, 2018

Choose a reason for hiding this comment

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

Don't you want to rename the executables any more?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Upstream is doing that for me...

Copy link
Member

Choose a reason for hiding this comment

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

Perfect.

@dotlambda
Copy link
Member

dotlambda commented Jul 8, 2018

@leenaars

Please still do use the pythonPackages prefix in the commit message.

@dotlambda
Copy link
Member

@GrahamcOfBorg build python2.pkgs.authres python3.pkgs.authres
@GrahamcOfBorg build python2.pkgs.dkimpy python3.pkgs.dkimpy

@GrahamcOfBorg
Copy link

Success on x86_64-linux (full log)

Attempted: python2.pkgs.authres, python3.pkgs.authres

Partial log (click to expand)

/build/authres-1.1.0
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/914mkrhnmsyl4jymsr6aznfvbinmwlbf-python3.6-authres-1.1.0
strip is /nix/store/4qvrxzxa535y8304mk195x50b6p9607d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/914mkrhnmsyl4jymsr6aznfvbinmwlbf-python3.6-authres-1.1.0/lib
patching script interpreter paths in /nix/store/914mkrhnmsyl4jymsr6aznfvbinmwlbf-python3.6-authres-1.1.0
checking for references to /build in /nix/store/914mkrhnmsyl4jymsr6aznfvbinmwlbf-python3.6-authres-1.1.0...
running install tests
/nix/store/prm3haaazarl0im0gs10ldsq0ydpka2a-python2.7-authres-1.1.0
/nix/store/914mkrhnmsyl4jymsr6aznfvbinmwlbf-python3.6-authres-1.1.0

@GrahamcOfBorg
Copy link

Success on x86_64-linux (full log)

Attempted: python2.pkgs.dkimpy, python3.pkgs.dkimpy

Partial log (click to expand)

Ran 82 tests in 0.667s

OK
.
----------------------------------------------------------------------
Ran 1 test in 0.028s

OK
/nix/store/3d5iqfl2f0kwrxxqxy9qxaszwhd57vg9-python2.7-dkimpy-0.8.1
/nix/store/kfb6iq6mf27mf1asads85b1xg7f1ych7-python3.6-dkimpy-0.8.1

@GrahamcOfBorg
Copy link

Success on aarch64-linux (full log)

Attempted: python2.pkgs.authres, python3.pkgs.authres

Partial log (click to expand)

these derivations will be built:
  /nix/store/1qwa5psd037wiwnnwdap9p73skz7cvz0-authres-1.1.0.tar.gz.drv
  /nix/store/g2ivdz0lcs6w260y10ca08kki948q94i-python3.6-authres-1.1.0.drv
  /nix/store/nwi8cwhd1p58r5zcqanqq6iv7dfl6485-python2.7-authres-1.1.0.drv
these paths will be fetched (1.00 MiB download, 5.78 MiB unpacked):
  /nix/store/9w0kf0iw7ky3ri67nslsdnxnjr13b4yp-python2.7-bootstrapped-pip-10.0.1
copying path '/nix/store/9w0kf0iw7ky3ri67nslsdnxnjr13b4yp-python2.7-bootstrapped-pip-10.0.1' from 'https://cache.nixos.org'...
waiting for locks or build slots...
/nix/store/7wf8hq8020wby8wvnmszy9vpwxp3a306-python2.7-authres-1.1.0
/nix/store/zmxh3ndcbqknizz2cdypm5vzixjrfdz4-python3.6-authres-1.1.0

@GrahamcOfBorg
Copy link

Success on aarch64-linux (full log)

Attempted: python2.pkgs.dkimpy, python3.pkgs.dkimpy

Partial log (click to expand)

Ran 82 tests in 0.969s

OK
.
----------------------------------------------------------------------
Ran 1 test in 0.039s

OK
/nix/store/ncpijw53ab49vc2rdzkipjacakp6lyrm-python2.7-dkimpy-0.8.1
/nix/store/mdbzxs6ih40a9lhcy2pvwsl1sx1lpjdd-python3.6-dkimpy-0.8.1

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

3 participants