 | Nix Milan | 107 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Nix Milan | 107 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 23 Nov 2025 | ||
 gecko | Ah questo non l'avevo visto, ci do un occhio. Comunque la bottom line è che si può fare, il che mi rende felice. | 11:36:14 |
 Francesco | In reply to geckoBeh in effetti se devi distribuire una .app ci sta. Romperesti il contratto che una .app in teoria puoi spostarla dove vuoi ma non è un grosso problema :P | 11:40:50 |
| Francesco | Potresti far partire un applescript che fa questo check e se no ti fa vedere un popup che ti chiede di spostarla in /Applications | 12:07:19 |
 Alessandro Candido | Sembra che tutte le build su MacOS siano in definitiva impure, perché da qualche parte finiscono per scontrarsi con un layer di primitive proprietarie | 12:07:24 |
| Francesco | (Dico applescript perché è il modo più semplice di far vedere una finestra su macos) | 12:08:02 |
| gecko | Non so, ho visto in giro NIX_STORE_DIR, ma non penso sia difficile. Di sicuro non voglio patchare a posteriori. | 12:02:35 |
| gecko | Comunque il mio obiettivo sarebbe fare tipo nix-bundle che ti cross-compila da Linux per Linux, Windows a macOS. Tutto producendo roba che non richiede root. | 12:06:02 |
| 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 |