Thank you! ... that seems like one of the variants I tried, but maybe I didn't get it quite right or there's a more subtle issue with this particular package ... I'll try again

I put a bit more of the intended usage context in the thread above, but have now summarized what was useful and pushed the original question which was largely confused below its break.

Thank you! ... that seems like one of the variants I tried, but maybe I didn't get it quite right or there's a more subtle issue with this particular package ... I'll try again

I put a bit more of the intended usage context in the thread above, but have now summarized what was useful and pushed the original question , which was largely confused by equivalent errors with different causes, below its break.

Thank you! ... that seems like one of the variants I tried, but maybe I didn't get it quite right or there's a more subtle issue with this particular package ... I'll try again

I put a bit more of the intended usage context in the thread above, but have now summarized what was useful and pushed the original question, which was largely confused by equivalent errors with different causes, below its break.

tl; dr: should've looked upstream first regarding the dm-tree package

since even after a heroic effort there this is broken on darwin, if you need crossplatform compatibility, probably one of the better approaches is to ensure chex>=0.1.82 and avoid dm-tree if not otherwise essential

If you'd like to combine override and overridePythonAttrs, using what K900 ⚡️ suggested below

              dm-tree = (super.dm-tree.override {preferWheel = false;}).overridePythonAttrs (
                old: {
                  nativeBuildInputs = (old.nativeBuildInputs or []) ++ [pkgs.cmake];
                }
              );

functions as expected, but the above does not work for the referenced package, dm-tree, because this doesn't come close to addressing the issues with its build.

The original question remains in the thread but is mostly confused.

But, of course, this doesn't really begin to get to the root of the issue, for which I definitely should've looked upstream first

https://github.com/NixOS/nixpkgs/blob/4e44fb9c2673c5b58c44deb7e05bcf312a5862cf/pkgs/development/python-modules/dm-tree/default.nix#L15

But, of course, this doesn't really begin to get to the root of the issue, for which I definitely should've looked upstream first

https://github.com/NixOS/nixpkgs/blob/4e44fb9c2673c5b58c44deb7e05bcf312a5862cf/pkgs/development/python-modules/dm-tree/default.nix#L15

especially at the cmake patch

https://github.com/NixOS/nixpkgs/blob/4e44fb9c2673c5b58c44deb7e05bcf312a5862cf/pkgs/development/python-modules/dm-tree/cmake.patch

tl; dr: should've looked upstream first regarding the dm-tree package

since even after a heroic effort there this is broken on darwin, if you need crossplatform compatibility, probably one of the better approaches is to ensure chex>=0.1.82 and avoid dm-tree if not otherwise essential

If you'd like to combine override and overridePythonAttrs, using what K900 ⚡️ suggested below

              dm-tree = (super.dm-tree.override {preferWheel = false;}).overridePythonAttrs (
                old: {
                  nativeBuildInputs = (old.nativeBuildInputs or []) ++ [pkgs.cmake];
                }
              );

functions as expected, but the above does not work for the referenced package, dm-tree, because this doesn't come close to addressing the issues with its build. Those are much better approximated in the cmake patch there.

The original question remains in the thread but is mostly confused.

Here's the gist of it:

$ nix log /nix/store/r01bqrznkq4bm9q29qwlrwr7f5vx7q3h-python3.11-pytorch-lightning-2.1.3.drv
Sourcing python-remove-tests-dir-hook
Sourcing python-catch-conflicts-hook.sh
Sourcing python-remove-bin-bytecode-hook.sh
Sourcing wheel setup hook
Sourcing pypa-install-hook
Using pypaInstallPhase
Sourcing python-imports-check-hook.sh
Using pythonImportsCheckPhase
Sourcing python-namespaces-hook
Sourcing python-catch-conflicts-hook.sh
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors

I've tried a couple different overrides, but none of them seem to take:

pytorch-lightning = pkgs.python311Packages.pytorch-lightning;

pytorch-lightning = super.pytorch-lightning.override { preferWheel = false; };

pytorch-lightning = super.pytorch-lightning.overridePythonAttrs (old: {
  unpackPhase = ''
    set -eux
    echo "THIS SHOULD NOT BUILD!"
    exit 1
  '';
});

I've tried specifying the dependency as both of these ways:

pytorch-lightning = "2.1.3"

pytorch-lightning = { url = "https://files.pythonhosted.org/packages/f6/95/a662bd12b255ee3b59c975277c67398410b5810ee72ff11e34134e10cc9a/pytorch_lightning-2.1.3-py3-none-any.whl" }

Even when directly pointing it directly at the wheel file, it still gives the same error

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from a test branch on my fork

https://github.com/cameronraysmith/poetry2nix/commit/aab624b6f49b5974a57a4be5d034613d6b65c79f

and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain them with version guards for backward compatibility.

I didn't manage to bisect where this must have changed in the pytorch-lightning release history but I tried as far back as 1.9.4.

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from an experimental branch on my fork
and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain the with version guards for backward compatibility.

I didn't manage to bisect where this must have changed in the pytorch-lightning release history but I tried as far back as 1.9.4.

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from an experimental branch on my fork
and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain these unpackPhase customizations with version guards for backward compatibility.

I could add these if I knew where things changed, but I didn't manage to bisect where this in the pytorch-lightning release history after trying as far back as 1.9.4 and sporadically downloading a few of the very early source distributions to inspect their structure.

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from an experimental branch on my fork
and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain these unpackPhase customizations with version guards for backward compatibility.

I could add these if I knew where things changed, but I didn't manage to bisect where that is in the pytorch-lightning release history after trying as far back as 1.9.4 and sporadically downloading a few of the very early source distributions to inspect their structure.

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from an experimental branch on my fork
and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain these unpackPhase customizations with version guards for backward compatibility.

I could add these if I knew where things changed, but I didn't manage to bisect where that is in the pytorch-lightning release history after trying as far back as 1.9.4 and sporadically downloading a few of the very early source distributions from PyPI to inspect their structure.

knkski: there are default overrides for  pytorch-lightning  that attempt to handle what must have previously been something like a nested tarball. I removed these from an experimental branch on my fork and things work as expected when I source it in my flake. I was going to discuss submitting these upstream, but it might be necessary to retain these unpackPhase customizations with version guards for backward compatibility.

I could add these if I knew where things changed, but I didn't manage to bisect where that is in the pytorch-lightning release history after trying as far back as 1.9.4 and sporadically downloading a few of the very early source distributions from PyPI to inspect their structure.