Strange MKL dependency + allowUnfree error

[tbenst]

Ok I'm baffled...I have { allowUnfree = true; } in my ~/.config/nixpkgs/config.nix and furthermore, I do not use MKL in any python overlays as it breaks scikit-learn.

I have two nearly identical shells other than one using vanilla jupyter and the other jupyterWith:
https://gist.github.com/tbenst/c88da1138628a6be1d5b88d3a9337f2a

The former builds fine, but the latter gives:

error: Package ‘mkl-2019.5.281’ in /nix/store/mi8xmwmybbxa8w7062j1b00q6x42x6gc-source/pkgs/development/libraries/science/math/mkl/default.nix:110 has an unfree license (‘issl’), refusing to evaluate.

Note that nix-shell -p mkl also works fine. Any idea what could be happening?

[mrobakowski]

I had the same thing happen. For now, I just worked around this by running

NIXPKGS_ALLOW_UNFREE=1 nix-shell

instead of just nix-shell.

[tbenst]

I think https://github.com/tweag/jupyterWith/blob/b12e8296a736725690ba73831cc987ce1c016275/default.nix#L2 is the culprit--not sure this is needed...or at least should default to ~/.config/nixpkgs/config.nix. I understand why ignoring overlays unless user opts in may be a good thing for reproducibility / cachix, but don't see the same benefit for config.nix

[guaraqe]

The Nixpkgs used by JupyterWith is overrided, and pinned by the commit used in the repo. Since the configuration is defined for each Nixpkgs, it has to be set up manually. The nixpkgs/config.nix file is some magic that only works with the main channel.

For the unfree problem, you can set: { config = { allowUnfree = true; }; } so that MKL builds without using environment variables.

For the problem of having MKL in the dependency graph, did you manage to track which dependency brings with JupyterWith?

[alexvorobiev]

@tbenst This could be off-topic but we configured numpy with MKL in an overlay and so far haven't had any complaints about scikit-learn. Could you please share what is broken?

[djacu]

Closing out old issues with no activity in preparation for migration to the next branch.