Sender | Message | Time |
---|---|---|
5 Oct 2025 | ||
14:59:14 | ||
In reply to Federico TCiao! Sei sicuro sta leggendo il file che pensi tu? Magari puoi provare a "spaccarlo"/cancellarlo | 15:30:51 | |
In reply to AlbertoSi ho provato a romperlo e si è effettivamente rotto | 15:56:55 | |
Ma io farò come fanno in nixpkgs e metterò un bel extraRules e si vola. | 18:40:44 | |
Madò ho capito perché non-ricordo-il-nome di Torino aveva detto di fare la config di nftables con i moduli, così le cose si possono automergiare tra diversi moduli che contribuiscono in maniera indipendente alle regole del firewall 🤯 | 18:40:00 | |
Se non ricordo male ci sono degli helper in lib che puoi usare per dire alla merge function di mettere qualcosa prima o dopo di qualcos'altro | 20:06:01 | |
È un po' macchinoso in effetti | 20:06:08 | |
In reply to gecko(il tizio di Torino sono io) sì infatti io preferisco creare delle opzioni perché poi posso definire pezzi di configurazione in moduli diversi! | 19:54:05 | |
Ma le regole di iptables sono valutate in ordine, come vengono messe poi nello script finale? | 19:57:41 | |
Le cose che devo fare io sono abbastanza ortogonali tra loro e dovrebbe venire fuori bene. Non so sarebbe abbastanza generale da coprire tutti gli use case e, per dire, andare in nixpkgs. | 20:11:06 | |
Tranquillo lol anch'io | 20:21:19 | |
In reply to FrancescoSorry ma coi nomi son pessimo | 20:17:00 | |
6 Oct 2025 | ||
In reply to FrancescoSecondo me è chiaramente qualcosa con cui fare il callo. Ma non è così terribile. Se hai poche occorrenze, puoi usare mkBefore/mkAfter. Se ne hai tante, cominci a usare mkOrder 1000, 2000, 3000... che poi è quello che fai tipicamente anche coi file in etc/ quando la configurazione è in una cartella e non in un unico file https://nixos.org/manual/nixos/stable/#sec-option-definitions-ordering | 03:23:10 | |
si è un workaround 🤷♂️ | 07:36:30 | |
se non ha un default significa che viene valutata solo nei casi in cui è obbligatorio metterci un valore, in quel caso probabilmente sai che valore vuoi metterci | 07:39:09 | |
Io quello intendevo per "unsettare" | 07:46:01 | |
Non funziona sempre pero', se un default non ce l'ha? | 07:37:17 | |
Non puoi neanche togliere elementi da una lista gia' settati in altri moduli che io sappia (o forse c'era un modo? O un workaround?) | 07:43:32 | |
Il module system e' veramente versatile, puoi anche creare dei nuovi tipi che "mergiano" come vuoi te. L'unico limite che mi da fastidio con cui spesso mi sono scontrato e' che non puoi "unsettare" un'opzione settata un altro modulo. | 07:35:18 | |
Questo e' vero anche per i freeform module? Tipo se importo un modulo che mi setta app.settings.chiave (che e' un freeform module diciamo) ma io non voglio ce chiave appaia nel json/toml/quello che e' | 07:42:50 | |
me le segno e controllo, non avevo mai pensato al primo caso | 07:44:22 | |
non so se si può fare qualche magia facendo un modulo wrapper | 07:47:47 | |
Puoi forzare il valore a il suo default | 07:36:03 | |
tecnicamente è vero, non si può fare unset, non c'è un valore per "undefined" | 07:39:46 | |
nel secondo in non vuoi fare "unset" del valore, vuoi proprio togliere una definition e non si può fare | 07:45:11 | |
E comunque non lo usi da dentro il modulo stesso, devi prendere il punto fisso gia' computato | 07:53:16 | |
Ma e' computazionalmente pesante | 07:52:20 | |
non si può fare il filter perché: - se fai il set alla stessa priorità diventa un infinite recursion - se fai il set a una priorità più alta non hai accesso alla versione calcolata delle altre priorità | 07:51:10 | |
esatto, stavo per scrivere la prima! Forse puoi usare extendModules | 07:51:58 | |
o forse si, ma è una cosa così internal che non la userei comunque | 07:51:30 |