Unable to override cryptography package

[takeda]

Not sure why, but it looks like it isn't possible to override cryptography package.

It looks like an issue was raised here: #1337, but the original author closed it because update to cryptography was pushed and the override was no longer needed.

Here's example of override:

       cryptography = super.cryptography.overridePythonAttrs (old: rec {
         cargoDeps = pkgs.rustPlatform.fetchCargoTarball {
           inherit (old) src;
           name = "${old.pname}-${old.version}";
           sourceRoot = "${old.pname}-${old.version}/${cargoRoot}";
           sha256 = "sha256-h6TjGcn81TSQuu+16ty60e6P07uH2gXa3VmG+Vy3eu0=";
         };
         cargoRoot = "src/rust";
       });

And I still get error that the hash is not being set:

error: hash mismatch in fixed-output derivation '/nix/store/frmbd8isi3bvaxiniqxq2mf7jgv0fs7z-cryptography-42.0.0-vendor.tar.gz.drv':
         specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
            got:    sha256-h6TjGcn81TSQuu+16ty60e6P07uH2gXa3VmG+Vy3eu0=
error: 1 dependencies of derivation '/nix/store/cwjy9g8rbgrfbmp3s01gcd88cg16q700-python3.10-cryptography-42.0.0.drv' failed to build

It's surprising because overriding other packages works.

[sigprof]

This probably does not work due to the change in #899 — poetry2nix.overrides.withDefaults applies the user overrides before the default overrides, and therefore the user override does not really take effect. As a workaround, you can do something like this:

  overrides = [ poetry2nix.defaultPoetryOverrides (self: super: {
    # ... package overrides here ...
  }) ];

[justuswilhelm]

@takeda

Hi, thanks to your snippet I was able to update cryptography to 42.0.4. My patch looked like this:

diff --git a/backend/flake.nix b/backend/flake.nix
index 1e4a34fb..f227fd13 100644
--- a/backend/flake.nix
+++ b/backend/flake.nix
@@ -68,6 +68,15 @@
               buildInputs = (old.buildInputs or [ ]) ++ [ super.hatchling super.setuptools ];
             }
           );
+          cryptography = super.cryptography.overridePythonAttrs (old: rec {
+            cargoDeps = pkgs.rustPlatform.fetchCargoTarball {
+              inherit (old) src;
+              name = "${old.pname}-${old.version}";
+              sourceRoot = "${old.pname}-${old.version}/${cargoRoot}";
+              sha256 = "sha256-qaXQiF1xZvv4sNIiR2cb5TfD7oNiYdvUwcm37nh2P2M=";
+            };
+            cargoRoot = "src/rust";
+          });
         });
         poetryEnv = mkPoetryEnv {
           inherit projectDir;

See this commit here

My overrides are created with

        overrides = defaultPoetryOverrides.extend (self: super: {

based off the poetry2nix flake guide, and just like @sigprof here recommended as well -- so perhaps that made a difference?

[bow]

I am seeing this with cryptography 43.0.0 as well (currently the most recent release). I can also confirm that the workaround above works (thanks @justuswilhelm!).

EDIT: I guess I wrote too soon :( ~ the workaround above does not work, cryptography switched to maturin recently. With just the workaround above, it fails to build complaining maturin can not be found.

However, I can't help but feel that this is an awkward way to address the underlying problem: that poetry2nix does not get updated with the same frequencey as packages in PyPI. As a consequence, there will always be packages whose SHA-256 checksum gets rejected by poetry2nix. If for every package that breaks this way, one has to be aware of how it was built and apply the workaround accordingly (e.g. with Rust here, for cryptography), it defeats the point of using poetry2nix in the first place IMO.

Would it then make sense to expose a simpler override API in addition to the current one, that simply takes as input these things: the package name, the published PyPI version, and its expected SHA-256?

We'd then have a way to override just the necessary bits, and remove these manual overrides when poetry2nix is updated.

[spinus]

@sigprof this advice saved me another hours, thank you very much. I'll try to push that to FAQ