Hi Sander, > As a special case, there is also a 'wrapper' type [...]
I'm actually using 'wrapper' type, and I currently don't see why you would need to provide those activation scripts with disnix-service. I'm simply generating wrapper scripts for each service and thus I have access to the whole environment - it's much easier to change those scripts this way - they are simply part of the deployment. This is also why I needed to use nested attribute sets in infrastructure.nix - I simply want to put per-host configuration parameters here (however they look like). At the same time I don't care about passing infrastructure's parameters as environment variables to wrapper (because, as I said, I generate those scripts and thus have access to all the necessary information). On the other hand I think it would be nice to receive the path of previous version of the service as environment variable... Anyway I'll try to make everything more clear when I clean up everything and try to describe my whole setup. > Ok, thanks for pointing this out. I think I should restrict the usage > of sub attribute sets or at least make sure that they don't wreck > havoc, as they can't be used directly by the activation scripts (in > build expressions they can though). I will implement a fix for this > ASAP. As I said above - I would actually find it useful to use nested attributes, but my use case for 'wrapper' type script is different than yours. -- Best regards, Kamil _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
