pkgs.haskellPackages.lens.overrideAttrs {
  version = "5.3.3";
  src = pkgs.fetchzip {
     url = "mirror://hackage/lens-5.3.3/lens-5.3.3.tar.gz";
     hash = "sha256-3xm0+HH2CY3rcigl8x1kYVLOW5PVFhilg0s0hxHxzWE=";
  };
};

In reply to @implicit_operative:matrix.org

Maybe something like this?

lens_5_3_3 = pkgs.haskell.lib.callHackageDirect {
  pkg = "lens";
  ver = "5.3.3";
  sha256 = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
} {};

In reply to @b:chreekat.net
They're fundamentally in conflict. You only avoid conflict precisely by applying them loosely. :) DRY, applied religiously, requires you to define abstractions very early that allow slightly different use cases to share common expressions. But abstractions have a cost. Copy/paste/modify is often cheaper. And most importantly, it requires a lot less careful thought. Wasting brainpower to develop a thoughtful abstraction for something that will never have more than two use cases is a shame. That's really the essence of YAGNI.

In reply to @b:chreekat.net
They're fundamentally in conflict. You only avoid conflict precisely by applying them loosely. :) DRY, applied religiously, requires you to define abstractions very early that allow slightly different use cases to share common expressions. But abstractions have a cost. Copy/paste/modify is often cheaper. And most importantly, it requires a lot less careful thought. Wasting brainpower to develop a thoughtful abstraction for something that will never have more than two use cases is a shame. That's really the essence of YAGNI.

That's hardly the bare minimum needed to avoid repetition.

Perhaps DRY fails to explicitly account for the idea that some repetition is needed for defining things that are different even though they seem similar.

For me, problems like this tend to go away when I model the problem more carefully.

chreekat linj: Thanks for the hints back then. Does haskell.lib.compose.overrideCabal (as in both pretty-simple and nixfmt-rfc-style) can do the same as

haskell.packages.ghc910.callPackage and haskellPackages = haskell.packages.ghc910;?

I really need ghc910 (GHC2024).

chreekat linj: Thanks for the hints back then. Does haskell.lib.compose.overrideCabal (as in both given derivation examples pretty-simple and nixfmt-rfc-style) can do the same as

haskell.packages.ghc910.callPackage and haskellPackages = haskell.packages.ghc910;?

I really need ghc910 (GHC2024).

In reply to @joaomoreira:matrix.org

how can I move, haskell.lib.compose.justStaticExecutables, haskell.packages.ghc910 etc from all-packages.nix to package.nix so that nixpkgs-vet job succesffully passes (i.e. fits pkgs/by-name)? I tried finding examples on nixpkgs, but they don't seem right / too complex for my derivation.

How it is now:

pkgs/top-level/all-packages.nix

  # Check kind-lang.cabal. GHC2024 >= ghc910.
  kind-lang = haskell.lib.compose.justStaticExecutables (haskell.packages.ghc910.callPackage ../by-name/ki/kind-lang/package.nix {
    haskellPackages = haskell.packages.ghc910;
  });

nixpkgs-vet error

- Because pkgs/by-name/ki/kind-lang exists, the attribute `pkgs.kind-lang` must be defined like

    kind-lang = callPackage ./../by-name/ki/kind-lang/package.nix { /* ... */ };

  However, in this PR, it isn't defined that way. See the definition in pkgs/top-level/all-packages.nix:6458

    kind-lang = haskell.lib.compose.justStaticExecutables (haskell.packages.ghc910.callPackage ../by-name/ki/kind-lang/package.nix {
      haskellPackages = haskell.packages.ghc910;
    });

This PR introduces the problems listed above. Please fix them before merging, otherwise the base branch would break.
To run locally: ./ci/nixpkgs-vet.sh master https://github.com/NixOS/nixpkgs.git
If you're having trouble, ping @NixOS/nixpkgs-vet
Error: Process completed with exit code 1.

pr https://github.com/NixOS/nixpkgs/pull/371934