!OHimLTKAXNbFrEoogf:matrix.org

Nix Milan

125 Members
https://milano.nix.pizza/9 Servers

Load older messages

SenderMessageTime
1 Apr 2026
@telegram_73824637:t2bot.ioAndrea Ciceri E' lento perche' usa le IFD per risolvere le dipendenze.
Ma e' un problema che o risolvi con le IFD o pre-generandoti dei file nix con le versioni delle dipendenze pinnate (tipo con callCabal2nix di nixpkgs), in entrambi i casi hai pro/contro.
Oppure accetti che nix non scarichi le versioni esatte che verrebbero risolte e usi quelle presenti nel package set di hasekll nella tua commit specifica di nixpkgs. 		11:08:37
@telegram_73824637:t2bot.ioAndrea Ciceri Non so come faccia haskell-flake di srid in realta' 11:09:37
@telegram_8556022534:t2bot.ioDragos ISi lo so che cabal-plan ha un commando che ti mostra che versioni di librerie sceglie, anche per le dipendenze transitive11:10:36
@telegram_8556022534:t2bot.ioDragos IIfd = ?11:10:57
@telegram_8556022534:t2bot.ioDragos I* IFD = ?11:11:18
@telegram_8556022534:t2bot.ioDragos I* Si lo so che cabal-plan ha un comando che ti mostra che versioni di librerie sceglie, anche per le dipendenze transitive11:11:46
@telegram_73824637:t2bot.ioAndrea Ciceri IFD sta per "import from derivation" e le hai quando scrivi derivazioni nix che producono in output codice nix che poi viene valutato. Per esempio nel caso di haskell.nix, la valutazione del codice nix viene interrotta ad un certo punto, poi viene buildata una derivazione che chiama dei tool custom che scimmiottano la risoluzione delle dipendenze che farebbe cabal e producono in output del codice nix con le versioni e gli hash delle dipendenze del plan, a quel punto la valutazione del codice nix prosegue importando ("import from derivation" per questo) questo codice nix autogenerato 11:15:46
@telegram_73824637:t2bot.ioAndrea CiceriL'alternativa e' fare questo passaggio prima a parte e committare il codice nix autogenerato nel tuo repo. Pero' e' "meno elegante" perche' hai 2 "source of truth" per le versioni e devi ricordarti te a mano di tenere aggiornato questo secondo lockfile11:16:50
@telegram_8556022534:t2bot.ioDragos IAha11:17:25
@telegram_73824637:t2bot.ioAndrea Ciceri Tra l'altro haskell.nix ha una meccanismo che chiama "materialization" che ti permette proprio di committare questo codice autogenerato evitando le IFD volendo 11:17:35
@telegram_41776856:t2bot.ioMarco TurchettoMai riuscito a farlo funzionare...11:18:13
@telegram_41776856:t2bot.ioMarco Turchetto* Mai riuscito a farlo funzionare... Mi sa che c'è pure una issiue11:18:51
@telegram_73824637:t2bot.ioAndrea Ciceri Comunque in realta' io in roba personale io sto usando callCabal2Nix di nixpkgs che puo' essere usato anche con le IFD (nonostante sia in nixpkgs e quando usato in nixpkgs tu non possa introdurre IFD per policy) 11:19:49
@telegram_73824637:t2bot.ioAndrea CiceriNon l'ho mai usato nemmeno io11:19:58
@telegram_8556022534:t2bot.ioDragos IUsavo 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 tutto11:30:16
@telegram_7189191315:t2bot.iogeckoNon AWS, ma sì. Ma poi ci son altri bug a caso, boh.12:20:21
@telegram_73824637:t2bot.ioAndrea Ciceri altre dipendenze haskell o di altro tipo? In teoria callCabal2Nix dovrebbe farti usare le versioni esatte delle dipenze 13:13:05
@telegram_8556022534:t2bot.ioDragos IAh! Si, di Haskell. Allora la mia interpretazione di cosa succedeva non era buona, devo rivisitare, grazie!14:38:45
@telegram_8556022534:t2bot.ioDragos 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
@telegram_8556022534:t2bot.ioDragos IAh no, ecco: “callCabal2Nix uses the package versions fixed by your nixpkgs, specifically the haskellPackages you are using) not the versions resolved by cabal-install14:59:08
@telegram_8556022534:t2bot.ioDragos 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
@telegram_73824637:t2bot.ioAndrea 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
@telegram_73824637:t2bot.ioAndrea 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
@telegram_73824637:t2bot.ioAndrea 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:matrix.orgnoib3 joined the room.09:48:07
5 Apr 2026
@telegram_7189191315:t2bot.iogecko 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
@telegram_73824637:t2bot.ioAndrea Ciceri https://nix.dev/manual/nix/2.18/command-ref/new-cli/nix3-registry 09:45:03
@telegram_7189191315:t2bot.iogeckoThanks09:47:48
@telegram_73824637:t2bot.ioAndrea Ciceri tra l'altro questo e' un flake valido dove puoi fare nix build 09:55:30
@telegram_73824637:t2bot.ioAndrea Ciceri 
{
  inputs = { };

  outputs = {nixpkgs, ...}: {
    packages.x86_64-linux = {
      default = nixpkgs.legacyPackages.x86_64-linux.hello;
    };
  };
}
09:55:35

Show newer messages

Back to Room ListRoom Version: 10