demize has quit [Remote host closed the connection]
demize has joined #nix-lang
joepie91___ has joined #nix-lang
joepie91___ has quit [Changing host]
joepie91___ has joined #nix-lang
joepie91 has quit [Ping timeout: 252 seconds]
__monty__ has joined #nix-lang
{^_^} has joined #nix-lang
ekleog has joined #nix-lang
joepie91___ is now known as joepie91
<infinisil>
ekleog: I also thought about this, but it sounded too limiting
<ekleog>
infinisil: so was saying, you could auto-generate a set that defines all identifiers of <= X chars
<ekleog>
I wonder how bad nix would suffer
<infinisil>
Nix is strict in attrset names
<ekleog>
and then allow user to define their own with defLispSymbol
<ekleog>
well, so long as it respects lisp naming convention… :°
<infinisil>
Let's say there's 64 valid chars for variables
<infinisil>
/symbols
<infinisil>
With 6 allowed letters
<infinisil>
> pow 64 6
<{^_^}>
68719476736
<ekleog>
> pow (26 + 1) 6
<{^_^}>
387420489
<ekleog>
hmm still too many, likely (counting only lowercase alpha and -)
<ekleog>
5 may be doable
<infinisil>
Yeah..
<infinisil>
> :v pow
<{^_^}>
pow = b: e: if e == 0 then 1 else b * pow b (e - 1)
<ekleog>
well, now to get the wanted behaviour, we'd need a JS-like getter for attribute sets
<ekleog>
hopefully that never gets into nix :°
<infinisil>
ekleog: Yeah that would be very nice!
<infinisil>
Wanted that before
<infinisil>
functions as attrsets
<ekleog>
for something actually useful, or for trollin'? :p
<infinisil>
Hehe
<infinisil>
I think I had an actually useful usecase
<infinisil>
trying to remember
<ekleog>
I can see many use cases for trollin', at least
<ekleog>
maybe that's enough?
<ekleog>
and then with (builtins.funAsAttrs (x: x)); nukes your scope :3
<infinisil>
Heh yeah
<infinisil>
Actually
<infinisil>
How would you represent the absence of an attribute in a function?
<ekleog>
well, we'd want the function to return (undefined | defined any)
<ekleog>
ideally
<infinisil>
builtins.funAsAttrs (name: hasPrefix "a" name) (x: x)
<infinisil>
First argument returns true for attribute names which exist
<infinisil>
Maybe
<ekleog>
oh that works too
<ekleog>
I was thinking having the main function either null or [ value ]
<ekleog>
(well, or either [] or [ value ])
<infinisil>
Ah yeah
<infinisil>
ekleog: Ah, i think my usecase was for a port -> service mapping
<ekleog>
not really sure this addition would actually be a good thing about the language, though… then well, anyway it can be emulated by just allocating lots of RAM, so…?
<ekleog>
yeah, it was functions for everything until I recently added functors into the mix, but I'm considering removing those and just having another function attribute
<ekleog>
like, the only point of the functors is to simplify writing, and I'm not actually really sure it improves things
<ekleog>
some day I'll actually use this in a VM on my NixOS and will make an announcement :)
<infinisil>
I see
<infinisil>
Now that I see that it does look a lot better than the module system
<infinisil>
Without all those recursion pitfalls
<ekleog>
well, there are still recursion pitfalls :°
<infinisil>
And more like how one would code in a normal language
<ekleog>
like, if you put an assert at the wrong place, it'll infinite recurse :(
<infinisil>
ekleog: I'd suggest to implement hierarchies of services. So that there is e.g. a toplevel postgresql, but also a foo-postgresql for service foo which needs a postgresql
<ekleog>
basically everything prepares a big state, and `operating-system` resolves the fixpoints (the service fixpoint, and the fs and block driver toposort)
<infinisil>
Neato
<ekleog>
infinisil: currently my idea is that foo-postgresql would just be foo { postgresql = "ID of the postgresql service"; }
<ekleog>
the question that you correctly raised is however how to propagate information backwards from postgresql to foo
<ekleog>
for how to connect to postgresql
<ekleog>
(question I've been considering with loggers up to now, still quite far from running pgsql I think :°)
<infinisil>
Why not each part getting its own instance/
<infinisil>
(I might be missing something here)
<ekleog>
oh, I meant “foo with postgresql” would be the attrset { postgresql = services.postgresql { pgsql config }; foo = services.foo { postgresql = "postgresql"; foo config }; }
<infinisil>
So that would use the "global" postgresql?
<ekleog>
yeah, basically every service in the attrset must be unique by name
<ekleog>
and other services depend on them by name
<ekleog>
I haven't found a better way to both handle dependencies and not duplicate dependencies, while allowing to have multiple instances of services running
<infinisil>
Yeah
<infinisil>
But how about service results (services.foo { ... }) returning both the service itself, but also the child services it needs to run
<ekleog>
hmmmmmm… actually thinking more about it maybe my issue with reverse-sending information from postgresql to foo could be solved by doing `rec { postgresql = ...; foo = { postgresql = postgresql.endpoint; ... }; }`? need to think more about it :)
<infinisil>
So that you have a service hierarchy { postgresql = { ... }; foo = { postgresql = { ... }; ...; }; }
<ekleog>
well, not all “extension relations” are child services, eg. iptables service
<infinisil>
hmm..
<ekleog>
in your example, would you want one or two postgresql services running?
<infinisil>
You could have 2
<infinisil>
One global, and one for foo
<infinisil>
the services could be named postgresql and foo-postgresql in the end
<ekleog>
but then what if I only want one in the end?
<ekleog>
(and to have foo use the global postgresql service)
<infinisil>
Ah yeah, I thought one would want to avoid that
<ekleog>
(with the current design, if I want two postgresql services, it'd be { postgresql = ...; foo-postgresql = ...; foo = { postgresql = "foo-postgresql"; ... }; })
<infinisil>
But I guess it makes sense to combine them because postgres can handle it
<infinisil>
Ah, that doesn't look half bad
<ekleog>
well, that said then I have to take care that postgresql instances are not in conflict myself for eg. files unless I start doing a behemoth where each service defines the files it uses, but… :°
<infinisil>
Doesn't QubeOS (or however it's spelled) run every service in its own VM?
<infinisil>
That would be fancy and super secure
<infinisil>
(but hella expensive..)
<ekleog>
Qubes OS runs every “security context” in a VM (it's not designed for server use, only for laptop use, so contexts may be “mail”, “bank”, “social network”, “development”, etc.)
<ekleog>
one of the plans of this design is to make it easily extensible to do that, by just having { vm-foo = run-vm (build-vm { cf. current example.nix }); }
<ekleog>
(with run-vm being a service that extends a service manager to be run, and maybe iptables to open ports)
<infinisil>
Ah, yeah I just read the section on security, neat (I didn't know much about it beforehand)
<ekleog>
yeah, qubes os is nice, also for the possibility of mixing distributions / OSes seamlessly :)
<infinisil>
That sounds pretty neat as well!
<infinisil>
(your idea)
<ekleog>
:D
* ekleog
happy to not be the only one thinking that
<infinisil>
My only worry with this project of yours is that it's too much to write
<infinisil>
NixOS configuration is super simple
<ekleog>
yeah… it's my worry too, I'll have to re-do each module :(
<ekleog>
I think I can make extenders as easy to write as NixOS configuration, but need more work towards factoring typechecking & co
<ekleog>
basically, I think I've done NixOS config's `config`, now I have to implement `options` :)
<ekleog>
that said hopefully `options` can be just a library of nix functions to combine extenders
<infinisil>
ekleog: Do you know Haskell?
<ekleog>
and then I'd have to simplify a bit the writing of extenders, but going from [ { extends = name; data = [ {} {} ]; } ] to { ${name} = [ {} {} ]; } is already on the todo-list and should be helpful
<infinisil>
I thought about doing something module system like in a typed approach
<infinisil>
But haven't gotten very far
<ekleog>
yeah, I think I could type my approach if I had a powerful enough type system
<ekleog>
like, extenders each have a type depending on what they extend
<infinisil>
Yeah, your approach in Nix sounds like the best course for that
<ekleog>
the thing I'm most happy with is the separation between end-user arguments and inter-module extenders, tbh :)
<infinisil>
:D
ekleog has quit [Remote host closed the connection]
ekleog has joined #nix-lang
<ekleog>
while evaluating anonymous function at /nix/store/8ix2ir94klgxzbxm2081qjx4hlgcywwp-nixos-18.03.133245.d16a7abceb7/nixos/lib/attrsets.nix:224:10, called from undefined position:
<ekleog>
^ didn't notice until now it was possible to make nix burp “from undefined position”
* ekleog
got nerdsniped into re-doing the service-solving fixpoint with the nicer-to-use syntax
<ekleog>
hmm wait maybe this should go back to #nixos-chat, actually? or maybe discussing the various ways of doing fixpoints is on-topic here? meh, time to sleep here anyway :)
<infinisil>
ekleog: Neat, would probably also make sense for the files there to be an attrset