| 16 Dec 2025 |
 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 |
| Alessandro 🤔➖☀️🖌 | ho provato a usare nix-prefetch-url su quel file, ma ottengo un hash ancora diverso 😅 | 13:43:33 |
 Matteo Joliveau | sisi e per quello dicevo che in spirito l'idea è corretta, ma nel momento in cui comunque ho del codice che deve integrarsi con PG tocca testarlo e per quello serve il db vero, perchè a mockarlo rischi incongruenze
le query che farai tra SQLite e PG saranno comunque diverse | 14:06:53 |
 gecko | In reply to Matteo Joliveau
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) > devi comunque testare il codice che implementa l'integrazione col sistema reale
Certo, però l'idea è che la gran parte dei bug li puoi beccare con oneri infrastrutturali minimi (i.e., no postgres).
> SQLite e postgres non sono intercambiabili, il mito che tutti gli SQL sono uguali è appunto un mito
Beh chiaro, ma o usi un livello di astrazione che si sbatte per te quelle cose (e.g., Django) oppure te lo rolli tu. Non sto dicendo di riusare le query SQL, sto dicendo di avere uno "storage provider" astratto di cui poi hai un'implementazione che usa SQLite e una che usa postgres.
Ad esempio noi facciamo così, anche perché abbiamo una modalità "utente singolo standalone da CLI" e una modalità "cloud". E per la prima chiaramente non vogliamo usare postgres :P.
La bottom line di quel che volevo dire è: to the extent to which is possible, è meglio mockuppare le dipendenze noiose da un punto di vista di set up, piuttosto che cercare necessariamente di deployare un'infrastruttura simil-prod per gli sviluppatori. | 14:05:36 |
 Lucio | Wow!! C'è anche la versione flake? | 16:57:20 |
| Lucio | Richiesta assurda: sapete se posso lanciare da NixOS una vm Nixos con la mia stessa configurazione (stile Windows sandbox) senza installare la iso da QEMU o simili? | 16:50:20 |
