| 15 Dec 2025 |
 Sergio Besana | Uso KDE. | 21:10:35 |
| 16 Dec 2025 |
 gecko | @x71c9 Comunque stavo ripensando al problema di avere servizi che runnano quando fai dev (e.g., redis o postgres) vs quando sei in prod.
Forse, più che cercare di far andare redis e postgres sulla macchina del dev con roba tipo devenv, un design più sano sarebbe mockuppare quei servizi per lo sviluppatore. Ad esempio usare sqlite invece di postgres e qualcosa di più ignorante al posto di redis.
Chiaramente non è sempre fattibile e ci son dei costi in complessità, però è un'opzione da tenere in considerazione. | 10:20:24 |
 Matteo Joliveau | In reply to gecko
@x71c9 Comunque stavo ripensando al problema di avere servizi che runnano quando fai dev (e.g., redis o postgres) vs quando sei in prod.
Forse, più che cercare di far andare redis e postgres sulla macchina del dev con roba tipo devenv, un design più sano sarebbe mockuppare quei servizi per lo sviluppatore. Ad esempio usare sqlite invece di postgres e qualcosa di più ignorante al posto di redis.
Chiaramente non è sempre fattibile e ci son dei costi in complessità, però è un'opzione da tenere in considerazione. Ci sono due problemi con questo approccio (che non è sbagliato in spirito, sia chiaro):
- devi comunque restare il codice che implementa l'integrazione col sistema reale, e per farlo ti serve avere la dipendenza vera. Che sia via testcontainers, docker-compose o altro
- SQLite e postgres non sono intercambiabili, il mito che tutti gli SQL sono uguali è appunto un mito. Anche senza andare ad usare feature non standard, ci sono sottili differenze nell'implementazione (esempio @ caso: in SQLite le primary key possono essere null, in Pg no) | 10:41:33 |
 x71c9 | @gecko4242 Sì anche così non sarebbe male. Sarebbe bello avere un metodo che fa mock di qualunque servizio. | 10:26:00 |
| Matteo Joliveau | * Ci sono due problemi con questo approccio (che non è sbagliato in spirito, sia chiaro):
- devi comunque testare il codice che implementa l'integrazione col sistema reale, e per farlo ti serve avere la dipendenza vera. Che sia via testcontainers, docker-compose o altro
- SQLite e postgres non sono intercambiabili, il mito che tutti gli SQL sono uguali è appunto un mito. Anche senza andare ad usare feature non standard, ci sono sottili differenze nell'implementazione (esempio a caso: in SQLite le primary key possono essere null, in Pg no) | 10:43:34 |
 Andrea Ciceri | Se passi --use-substitutes che succede? | 12:30:41 |
| Andrea Ciceri | Cosa vedi buildare due volte? | 12:26:34 |
| Andrea Ciceri | nix build <flake>#nixosConfigurations.<host>.config.system.build.toplevel sulle due macchine e poi confronti l'output? In realta' dovresi confrontare tutte le dipendenze | 12:20:12 |
| Andrea Ciceri | Se non sbaglio nixos-rebuild builda pure nix stesso prima di fare il deploy, magari vedi quello? | 12:28:00 |
 Alessandro 🤔➖☀️🖌 | in teoria i flake sono ermetici quindi mi aspetterei che nulla, nemmeno la versione di nix, abbia un impatto. ma anche assumendo che nix abbia un impatto, ora sto usando la stessa versione | 12:23:51 |
| Alessandro 🤔➖☀️🖌 | no, vedo 3000+ pacchetti da scaricare, secondo me è tutto tutto | 12:28:21 |
| Alessandro 🤔➖☀️🖌 | Diciamo che sto facendo nixos-rebuild di un flake (stesso commit) da 2 host diversi: come faccio a verificare che la derivazione che stanno costruendo sia effettivamente la stessa? | 12:17:40 |
| Alessandro 🤔➖☀️🖌 | la build dovrebbe avvenire su foo in entrambi i casi, il flake è lo stesso (garantito da git), quindi... perché? | 12:25:35 |
| Andrea Ciceri | Ah, interessante, non ne ho idea allora | 12:30:19 |
| Andrea Ciceri | Da due macchine diverse dai nixos-rebuild switch --flake <flake>? | 12:24:27 |
| Alessandro 🤔➖☀️🖌 | uhm, di base tutto: stavo facendo un update a 25.11, l'ho fatto da un host A, poi da un host B, e da B ha scaricato tutto di nuovo | 12:28:04 |
| Alessandro 🤔➖☀️🖌 | nixos-rebuild switch --build-host root@foo --target-host root@foo --flake .#foo
| 12:24:55 |
| Alessandro 🤔➖☀️🖌 | copying 3237 paths...
copying path '/nix/store/02f9qyjmkcak2ywwzb3571n0mggj8g58-tail.patch' to 'ssh://root@foo'...
etc
| 12:29:06 |
| Alessandro 🤔➖☀️🖌 | in realtà la domanda più fondamentale che ho è: perchè se faccio nixos-rebuild da due macchine diverse dello stesso flake la rebuild viene fatta 2 volte anziché 1 sola? da cui la domanda sopra | 12:22:58 |
| Alessandro 🤔➖☀️🖌 | uguale, con quel flag comunque copia i pacchetti che mancano | 12:32:09 |
| Alessandro 🤔➖☀️🖌 | forse dovrei "scomporre" nixos-rebuild in passi più fondamentali e vedere cosa sta facendo | 12:35:27 |
| Alessandro 🤔➖☀️🖌 | ma le due build sono avvenute a 20 min di distanza, quindi anche fosse quello è molto improbabile direi | 12:33:35 |
| Alessandro 🤔➖☀️🖌 | provo | 12:31:34 |
| Alessandro 🤔➖☀️🖌 | no, non è automatico | 12:33:07 |
| Andrea Ciceri | Al massimo --use-substitutes fara' si che la copia avvera' dalla cache a foo invece che dalla tua macchina a foo | 12:32:17 |
| Andrea Ciceri | Pero' comunque non dovresti vedere proprio che li copia | 12:31:37 |
| Andrea Ciceri | Magari il garbage collector ha cancellato roba? | 12:32:47 |
| Andrea Ciceri | Fa sapere se scopri perche' fa cosi'
Altrimenti se ti interessa solo il risultato potresti tentare con [nh](https://github.com/nix-community/nh) (ne parlavamo sabato). Io ancora devo provarlo. | 13:23:00 |
 Tonio | Consiglio molto :D | 13:33:31 |
| Alessandro 🤔➖☀️🖌 | ok grazie, provo a guardarci appena riesco.
nel frattempo, altra cosa bizzarra passando alla 25.11: fetchurl ora mi ritorna un hash diverso per un file che non è cambiato. e.g. ho fetchurl { url = "https://foo/bar"; hash = "blah"; } e mi dice che ora l'hash è divero, ma il contenuto è lo stesso | 13:43:09 |
