 | Nix Milan | 111 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Nix Milan | 111 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Nov 2025 | ||
 Alessandro Candido | https://daiderd.com/2020/06/25/nix-and-libsystem.html | 12:06:30 |
 gecko | Migliorare l'esperienza utente si può lavorarci, per intanto mi interessa sapere che si può fare. Grazie dell'idea comunque. | 12:08:49 |
| gecko | > Non credo che settare quella opzione cambi l'hash delle derivazioni Credo proprio di sì invece, sarebbe tragico il contrario | 12:08:15 |
 Andrea Ciceri | Non conosco NIX_STORE_DIR ma assumo sia equivalente a --store <store> (che dovrebbe essere equivalente a --option store <store>). Tra l'altro mi chiedo come funzioni in termini di binary cache siccome i path che sostiuisci usando le cache hanno gia' dentro /nix/store hardcodato. Quindi cosa succede? Non credo che settare quella opzione cambi l'hash delle derivazioni quindi comunque dovrebbero venire sostituite uguale | 12:07:27 |
| Alessandro Candido | In reply to Andrea Ciceri Da quanto capisco il "chroot dello store" non funziona su macos senza essere rootComunque sì, apparentemente Nixie usa esattamente quella feature. E sembra che si siano fatti fakedir perché a loro due non funge su MacOS. Quindi, a meno che non sia cambiato qualcosa, non è un’opzione… Peccato. Altrimenti, secondo me, era way-to-go | 12:02:23 |
| Andrea Ciceri | ok si puo' aver senso domanda piu' tecnica ora: come fai a dire a nix di buildare usando uno store diverso? Usi direttamente nix build --store /Applications/MyApp.app/nix/store quando buildi la derivazione? Buildi normalmente in /nix/store e poi usi patchelf (o l'equivalente per macos)? In questo caso ti patcha solo le librerie pero', non eventuali altri path hardcodati tipo in script o file di testo | 12:01:27 |
| Alessandro Candido | In reply to Andrea CiceriMai provato. Sul mio Mac Nix è ovviamente /nix/store, e non ho mai avuto accesso diretto a un Mac server (oltre ai runner di GitHub) | 11:58:24 |
| gecko | In reply to Andrea CiceriPotrei decidere di fare un .dmg non portabile e dirti "plz mettimi in /Applications" all'avvio se non ci sono già. Se l'utente è del gruppo admin (che mi dicono dalla regia è diverso da root) posso anche chiedergli "vuoi che mi autosposti in /Applications?". Comunque penso sia accettabile richiedere di stare in /Applications, non è la fine del mondo. | 11:53:54 |
| Alessandro Candido | A questo punto, non puoi compilare direttamente tutto linkando ogni cosa staticamente meno che le librerie di sistema? Ti verrà un binario grosso, ma se tanto dovresti comunque distribuire lo store non è che cambi poi molto. O no? | 12:08:38 |
 Francesco | Non mi ricordo le opzioni per farlo ma avevo visto un talk al riguardo un po' di tempo fa | 12:19:14 |
| Alessandro Candido | Come? | 12:19:10 |
| Andrea Ciceri | quindi mi sa che ti serve per forza un hack brutto tipo fakedir | 12:16:36 |
| Alessandro Candido | Però, se su Mac non funziona, mi sa che rimane quello sporco… | 12:18:17 |
| Alessandro Candido | Anch’io mi sarei aspettato lo stesso. Altrimenti crei una potenziale fonte di incompatibilità, mentre l’idea base di Nix è che tutto è compatibile proprio perché usi path universali in quanto assoluti (e con hash univoci) | 12:17:32 |
| Francesco | Ma in realtà si può cambiare il path dello store, l'unica cosa è che devi ricompilarti tutta la closure | 12:18:41 |
| Francesco | Se riesco lo trovo | 12:19:22 |
| Alessandro Candido | L’idea di chroot è un trucco pulito | 12:17:50 |
| Andrea Ciceri | Oppure patchare dopo il binario (ma comunque patchelf e simiili potrebbero non bastare per i path negli script e simili) | 12:17:15 |
| Andrea Ciceri |  Download image.jpeg | 12:10:41 |
| Andrea Ciceri |  Download image.jpeg | 12:15:35 |
| Andrea Ciceri | non lo so eh, pero' funziona comunque in qualche modo usare store diversi quindi qualche magia succede sotto | 12:10:41 |
| Andrea Ciceri | mi sa che /nix/store e' proprio sempre hardodato in tutti i path indipendentemente se fai il "chroot dello store" (giustamente direi in realta', senno' non sarebbe un chroot) | 12:15:35 |
| Alessandro Candido | Sto ancora leggendo la parte riguardo alla configurazione “a runtime” dello store, ma se il suo problema era solo scrivere sullo store, avrei fatto le build su un’altra macchina e poi scaricato la closure. Alla fine le cose di HPC sono pensate principalmente per eseguire. Non credo ti serva un cluster per fare una build… per quanto grossa possa essere… | 12:35:37 |
| Alessandro Candido | Ma il suo problema con lo store readonly nei job è che non può buildare sulle code? | 12:32:38 |
| Alessandro Candido | Ok, quindi sembra essere —with-store-dir. Corretto? | 12:37:57 |
| Alessandro Candido | In reply to Alessandro CandidoApparentemente questa era solo l’idea di base, sul fatto che la build deve diventare impura a livello di libSystem. Ma, adesso, è apparentemente peggio di quello che racconta nel post: sembra che non ci sia davvero una sola umbrella library standard per tutto nix-darwin https://discourse.nixos.org/t/on-the-future-of-darwin-sdks-or-how-you-can-stop-worrying-and-put-the-sdk-in-build-inputs/50574 | 12:27:06 |
| Andrea Ciceri | In reply to Francesconon e' proprio un dettaglio trascurabile. Inoltre anche assumendo che uno abbia voglia crearsi una binary cache ad hoc popolata dalla sua CI comunque non potrebbe condividere la stessa cache fra piu' progetti, perche' per ogni progetto ci sarebbe uno store diverso a secondo del nome dell'applicazione | 12:28:52 |
| Andrea Ciceri | In reply to Alessandro Candidoqua se ne parla: https://github.com/NixOS/nix/issues/10253 | 12:27:21 |
| Andrea Ciceri | no no intendevo che trovo della roba ma e' stato tolto, dovrei fare git blame per capire la commit e vedere se e' stato rinominato | 13:49:36 |
| Andrea Ciceri | ma qua il buon thufschmitt dice seh si puo' fare anche a runtime: https://github.com/NixOS/nix/issues/10253#issuecomment-2005839089 che onestamente e' meglio che ricompilare nix | 13:50:26 |