That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 it should be somewhere in the release prior to that Sep 22 2022 1.7.7 and the last one 1.9.4 I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 it should be somewhere in the release prior to that Sep 22 2022 1.7.7 and the last one 1.9.4 I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 it should be somewhere in the release prior to that Sep 22 2022 1.7.7 and the last one, 1.9.4, I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 it should presumably be somewhere in the release prior to that Sep 22 2022 1.7.7 and the last one, 1.9.4, I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 the change should presumably be somewhere in the release prior to that Sep 22 2022 1.7.7 and the last one, 1.9.4, I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 the change should presumably be somewhere in the release prior to that Sep 22 2022 1.7.7 and the oldest one, March 2 2023 1.9.4, I checked manually.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 the change should presumably be somewhere in the release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in #786 Oct 31 2022 the change should presumably be somewhere between the release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled in general rendering the unpackPhase unnecessary, even for older versions.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled in general rendering this unpackPhase unnecessary, even for older versions.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled rendering this unpackPhase unnecessary, even for older versions.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled rendering this unpackPhase unnecessary, even for older versions.

Anyway, I put up #1481 to mark the issue.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled rendering this unpackPhase unnecessary, even for older versions.

Anyway, I put up poetry2nix #1481 to mark the issue.

That sounds like a good start. I'll take a look around that time.

Since the unpackPhase was added in poetry2nix #786 Oct 31 2022 the change should presumably be somewhere between the pytorch-lightning release prior to that Sep 22 2022 1.7.7 and the oldest one I checked manually from March 2 2023 in 1.9.4.

Alternatively, there may have been a higher-level change in how the source tarball's are handled rendering this unpackPhase unnecessary, even for older versions.

Anyway, I put up poetry2nix #1481 to mark the issue for further discussion if it is worthwhile.

Hey y'all.
Can somebody explain me why

          projectDir = self;
          overrides =
            overrides.withDefaults
            (
              self: super: {
                rpds-py = super.rpds-py.overridePythonAttrs (old: {
                  cargoDeps = pkgs.rustPlatform.fetchCargoTarball {
                    inherit (old) src;
                    name = "${old.pname}-${old.version}";
                    sha256 = "sha256-aPmi/5UAkePf4nC2zRjXY+vZsAsiRZqTHyZZmzFHcqE=";
                  };
                });
              }
            );
        };

``` fails to evaluate cargoDeps at all, 

but when I switch the order in the list of  withDefaults in poetry2nix/defaults.nix, then that works (and a test case starts failing :) ).

I presume it's because the default override does replace the cargoDeps with it's own (failing) lookup.


But then I gotta ask: Shouldn't it be the other way around in withDefaults, so I can actually override those defaults?

Hey y'all.
Can somebody explain me why

          projectDir = self;
          overrides =
            overrides.withDefaults
            (
              self: super: {
                rpds-py = super.rpds-py.overridePythonAttrs (old: {
                  cargoDeps = pkgs.rustPlatform.fetchCargoTarball {
                    inherit (old) src;
                    name = "${old.pname}-${old.version}";
                    sha256 = "sha256-aPmi/5UAkePf4nC2zRjXY+vZsAsiRZqTHyZZmzFHcqE=";
                  };
                });
              }
            );
        };

```
 fails to evaluate cargoDeps at all, 

but when I switch the order in the list of  withDefaults in poetry2nix/defaults.nix, then that works (and a test case starts failing :) ).

I presume it's because the default override does replace the cargoDeps with it's own (failing) lookup.


But then I gotta ask: Shouldn't it be the other way around in withDefaults, so I can actually override those defaults?

Hey y'all.
Can somebody explain me why

          projectDir = self;
          overrides =
            overrides.withDefaults
            (
              self: super: {
                rpds-py = super.rpds-py.overridePythonAttrs (old: {
                  cargoDeps = pkgs.rustPlatform.fetchCargoTarball {
                    inherit (old) src;
                    name = "${old.pname}-${old.version}";
                    sha256 = "sha256-aPmi/5UAkePf4nC2zRjXY+vZsAsiRZqTHyZZmzFHcqE=";
                  };
                });
              }
            );
        };

fails to evaluate cargoDeps at all,

but when I switch the order in the list of withDefaults in poetry2nix/defaults.nix, then that works (and a test case starts failing :) ).

I presume it's because the default override does replace the cargoDeps with it's own (failing) lookup.

But then I gotta ask: Shouldn't it be the other way around in withDefaults, so I can actually override those defaults?