!RbXGJhHMsnQcNIDFWN:nixos.org

Haskell in Nixpkgs/NixOS

718 Members
For discussions and questions about Haskell with Nix, cabal2nix and haskellPackages in nixpkgs | Current Docs: https://haskell4nix.readthedocs.io/143 Servers

You have reached the beginning of time (for this room).


SenderMessageTime
19 Jan 2025
@alex:tunstall.xyzAlex
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.

13:24:44
@maralorn:maralorn.demaralornI think when modeling things more carefully always makes the result better. The question is does it make the process more efficient.13:28:32
@kenran_:matrix.orgkenran_ I've updated the hscurses library a little bit; in particular its new version would no longer need the line hscurses = addExtraLibrary pkgs.ncurses super.hscurses; in configuration-nix.nix (but would need to inherit ncurses from pkgs instead in the mkDerivation call in hackage-packages.nix instead in order to not pull in the Haskell lib named ncurses). Is the version update + the latter step something that's automagically made somehow? Or would that need a PR somewhere? 13:53:33
@kenran_:matrix.orgkenran_ * I've updated the hscurses library a little bit; in particular its new version would no longer need the line hscurses = addExtraLibrary pkgs.ncurses super.hscurses; in configuration-nix.nix (but would need to inherit ncurses from pkgs instead in the mkDerivation call in hackage-packages.nix instead in order to not pull in the Haskell lib named ncurses). Is the version update + the latter step something that's automagically made somehow? Or would that need a PR somewhere? (My guess would be that changing configuration-nix.nix is a manual step?) 13:54:12
@cdepillabout:matrix.orgcdepillabout Changes in configuration-nix.nix and configuration-common.nix are always manual steps. However the version updates are automatic. It happens about once every two weeks on the haskell-updates branch in Nixpkgs. (Although now its more like once a month or so?) Here's an example PR where you can see the version updates happen: https://github.com/NixOS/nixpkgs/pull/371032 14:03:26
@kenran_:matrix.orgkenran_ Cool, thanks! If I (or you) would want to make the above changes after the update to hscurses is through (and the package is then presumably marked broken), we'd then have to PR to haskell-updates when a new draft PR is made? 14:07:08
@kenran_:matrix.orgkenran_ And if hackage-packages.nix is automatically generated: is that mechanism smart enough to detect that the ncurses argument is not meaning haskellPackages.ncurses, but needs to be overridden with { inherit (pkgs) ncurses: }? 14:10:08
@kenran_:matrix.orgkenran_ * And if hackage-packages.nix is automatically generated: is that mechanism smart enough to detect that the ncurses argument is not supposed to need haskellPackages.ncurses, but needs to be overridden with { inherit (pkgs) ncurses: }? 14:11:39
@sternenseemann:systemli.orgsterni (he/him) I'd recommend using haskell.lib.compose.overrideSrc since that deals with hackage revisions and allows further haskell specific overrides. 19:12:17
@aspendowntime:matrix.org@aspendowntime:matrix.org changed their display name from Nerissa (it/she) to Eden (they/it/she).23:11:22
20 Jan 2025
@lambda-mike:matrix.org@lambda-mike left the room.10:22:02
@joaomoreira:matrix.orgJoão Moreira

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).

17:19:09
@joaomoreira:matrix.orgJoão Moreira *

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).

17:19:41
@joaomoreira:matrix.orgJoão Moreira
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

for reference
17:20:54
@joaomoreira:matrix.orgJoão Moreiraotherwise, how can I do it?17:21:59
@alexfmpe:matrix.orgalexfmpeyou can apply overrideCabal in an overlay for ghc910, just need nested //18:31:24
@alexfmpe:matrix.orgalexfmpe``` haskell = nixpkgs.haskell // { packages = nixpkgs.haskell.packages // { "${compiler}" = nixpkgs.haskell.packages.${compiler}.override(old: { overrides = self: super: { mypkg = overrideCabal super.mypkg (drv: ...) } }); }; }; }; ```18:37:05
@alexfmpe:matrix.orgalexfmpeThis sort of thjng18:37:08
@alexfmpe:matrix.orgalexfmpe* This sort of thing18:37:18
@alexfmpe:matrix.orgalexfmpe* <code> haskell = nixpkgs.haskell // { packages = nixpkgs.haskell.packages // { "${compiler}" = nixpkgs.haskell.packages.${compiler}.override(old: { overrides = self: super: { mypkg = overrideCabal super.mypkg (drv: ...) } }); }; }; }; </code> ```18:37:38
@alexfmpe:matrix.orgalexfmpe* <code> haskell = nixpkgs.haskell // { packages = nixpkgs.haskell.packages // { "${compiler}" = nixpkgs.haskell.packages.${compiler}.override(old: { overrides = self: super: { mypkg = overrideCabal super.mypkg (drv: ...) } }); }; }; }; </code>18:37:47
@alexfmpe:matrix.orgalexfmpe* ``` haskell = nixpkgs.haskell // { packages = nixpkgs.haskell.packages // { "${compiler}" = nixpkgs.haskell.packages.${compiler}.override(old: { overrides = self: super: { mypkg = overrideCabal super.mypkg (drv: ...) } }); }; }; }; ```18:38:42
@alexfmpe:matrix.orgalexfmpeIs triple back tick formatting broken for anyone else for weeks now?18:39:03
21 Jan 2025
@psibi:matrix.orgpsibi

I tried getting access to specific version of fourmolu like this:

nix shell nixpkgs#haskellPackages.fourmolu_0_16_2_0

But it results in an error. Relevant error messages:

CallStack (from HasCallStack):
withMetadata, called at libraries/Cabal/Cabal/src/Distribution/Simple/Utils.hs:368:14 in Cabal-3.10.3.0:Distribution.Simple.Utils
Error: Setup: Encountered missing or private dependencies:
Cabal-syntax >=3.12 && <3.13,
ghc-lib-parser >=9.10 && <9.11,
text >=2.1 && <3

Is that expected ? Is there any workaround for it ?

03:03:13

Show newer messages


Back to Room ListRoom Version: 6