| 1 Apr 2026 |
 Andrea Ciceri | Non l'ho mai usato nemmeno io | 11:19:58 |
 Dragos I | Usavo anche io callCabal2nix con ghcWithPackages di 25.11 per le dipendenze. Poi ho avuto bisogno di una libreria up to date, e quella richiede altre dipendenze, che non ci sono su 25.11 🙂, e poi avanti col spettacolo per trovare come pinnare le versioni e prendere versioni fresche di tutto | 11:30:16 |
 gecko | Non AWS, ma sì.
Ma poi ci son altri bug a caso, boh. | 12:20:21 |
| Andrea Ciceri | altre dipendenze haskell o di altro tipo? In teoria callCabal2Nix dovrebbe farti usare le versioni esatte delle dipenze | 13:13:05 |
| Dragos I | Ah! Si, di Haskell. Allora la mia interpretazione di cosa succedeva non era buona, devo rivisitare, grazie! | 14:38:45 |
| Dragos I | * Ah! Si, di Haskell. Allora la mia interpretazione di cosa succedeva non era buona, pensavo che usava solo le versioni pinnate da pkgs 25.11… devo rivisitare, grazie! | 14:56:02 |
| Dragos I | Ah no, ecco: “callCabal2Nix uses the package versions fixed by your nixpkgs, specifically the haskellPackages you are using) not the versions resolved by cabal-install | 14:59:08 |
| Dragos I | * Ah no, ecco: “callCabal2Nix uses the package versions fixed by your nixpkgs, specifically the haskellPackages you are using) not the versions resolved by cabal-install” | 14:59:15 |
| 2 Apr 2026 |
| Andrea Ciceri | Hai ragione, e' diverso da come pensavo.
buildPackages.runCommand "cabal2nix-${name}" { ... } ''
cabal2nix --compiler=${self.ghc.haskellCompilerName} \
--system=${hostPlatform.config} ${sha256Arg} "${src}" \
${extraCabal2nixOptions} > "$out/default.nix"
''
Questa e' l'IFD che fa callCabal2Nix, pero' se guardi come funziona cabal2nix (https://github.com/NixOS/cabal2nix) in realta' sputa fuori semplicemente un file nix con i nomi dei pacchetti, senza le versioni. Quindi puo quando nix builda la derivazione ottenuta tramtie IFD cabal verifica che le disponibili nel set haskellPackages della tua versioni di nixpkgs soddisfino i constraint di versione nel file cabal. Infatti in nixpkgs c'e' il fileone con tutti gli override di versione per i vari pacchetti haskell: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-common.nix
Questo fa si che quei progetti pero' non usino piu' le versioni delle dipendenze che dovrebbero essere risolte secondo i constraint nel loro cabal. | 08:26:07 |
| Andrea Ciceri | Quindi haskell2nix rimane comuque superiore da questo punto di vista perche' ti da le versioni esattamente come te le darebbe cabal. Infatti ora che ci penso in haskell.nix puoi variare la data dello snapshot di hackage e questo varia la risoluzione e quindi le versioni finali che vengono usate. | 08:27:25 |
| Andrea Ciceri | * Hai ragione, e' diverso da come pensavo.
buildPackages.runCommand "cabal2nix-${name}" { ... } ''
cabal2nix --compiler=${self.ghc.haskellCompilerName} \
--system=${hostPlatform.config} ${sha256Arg} "${src}" \
${extraCabal2nixOptions} > "$out/default.nix"
''
Questa e' l'IFD che fa callCabal2Nix, pero' se guardi come funziona cabal2nix (https://github.com/NixOS/cabal2nix) in realta' sputa fuori semplicemente un file nix con i nomi dei pacchetti, senza le versioni. Quindi poi quando nix builda la derivazione ottenuta tramtie IFD cabal verifica che le disponibili nel set haskellPackages della tua versioni di nixpkgs soddisfino i constraint di versione nel file cabal. Infatti in nixpkgs c'e' il fileone con tutti gli override di versione per i vari pacchetti haskell: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-common.nix
Questo fa si che quei progetti pero' non usino piu' le versioni delle dipendenze che dovrebbero essere risolte secondo i constraint nel loro cabal. | 08:29:52 |
| 3 Apr 2026 |
|  noib3 joined the room. | 09:48:07 |
| 5 Apr 2026 |
| gecko | Ho un sistema pulito senza channel (container nixos/nix). Quando faccio nix profile add nixpkgs#htop, come fa lui a sapere a cosa corrisponde nixpkgs? | 09:44:19 |
| Andrea Ciceri | https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-registry | 09:45:03 |
| gecko | Thanks | 09:47:48 |
| Andrea Ciceri | tra l'altro questo e' un flake valido dove puoi fare nix build | 09:55:30 |
| Andrea Ciceri | {
inputs = { };
outputs = {nixpkgs, ...}: {
packages.x86_64-linux = {
default = nixpkgs.legacyPackages.x86_64-linux.hello;
};
};
}
| 09:55:35 |
| 7 Apr 2026 |
 Edoardo Piccolotto | Ciao a tutti! Domanda. Qualcuno di voi usa Niri? | 09:38:58 |
 Francesco | Io sì | 09:39:31 |
| Edoardo Piccolotto | Io uso hyprland ma sto sentendo che niri è veramente una buona alternativa. | 09:41:09 |
| Edoardo Piccolotto | Come ti trovi? Lo consigli? | 09:41:39 |
| Francesco | Sì anch'io usavo hyprland ma mi sto trovando meglio con Niri | 09:42:20 |
| Francesco | Non mi piace tanto avere troppi workspace da gestire quindi avere tutto su uno o due workspace scrollabili per me è comodissimo | 09:45:39 |
| Francesco | Cioè secondo me il modello mentale è più semplice quindi faccio meno casino | 09:46:11 |
| Edoardo Piccolotto | Ho visto dei video a riguardo ed era la prospettiva che più mi intrigava... | 09:47:24 |
 Tonio Gela | Sottoscrivo, io lo uso e nella barra (di Noctalia) non ho nemmeno l'indicatore di "workspace" (niri ha una cosa vagamente simile ma in verticale) | 10:53:50 |
| Tonio Gela | Uso poche finestre e in generale le creo e distruggo ad un ritmo elevatissimo | 10:54:21 |
 Arialdo Martini | Ma che coincidenza incredibile. Ne stavo parlando adesso con Jaga Santagostino. | 11:06:32 |
| Arialdo Martini | Io sto sperimentando con un approccio iper-minimalista. Una cosa visualizzata alla volta. Ho dichiarato guerra a ogni popup, tutto sistematicamente full screen. Anche nell'IDE, 1 panel alla volta, full-screen. | 11:07:48 |
| Arialdo Martini | Jaga va un passo oltre: schermo gray-scale. Stile e-ink. Ci sto provando anche io. | 11:08:19 |
