ChanServ changed the topic of #nixus to: Nixus is an experimental deployment tool for NixOS systems - -
<cole-h> bqv: So, what did you actually do to get the streaming output logs? Just the fifo stuff? Or is there more magic?
<cole-h> Would be cool if you could PR that to nixus's current form... ;)
<bqv> cole-h: yeah fifo mostly, but it was easier with execline because I can juggle file descriptors and pipes like pingpong balls
<bqv> Id rather not implement it for bash (I'm not sure I can, I don't have enough confidence in bash's defined behaviour)
<cole-h> Understandable. Maybe link the magic in so infinisil can take a look at it and draw inspiration, at least? :P
<bqv> Sure :p
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixus
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixus
sphalerite has quit [Quit: WeeChat 2.6]
sphalerite has joined #nixus
<sphalerite> infinisil: I have a sort of wishlisty idea, should I comment it in #2 or open a new issue?
<sphalerite> nixus#2
<sphalerite> infinisil/nixus#2
<infinisil> Bot not here :P
<sphalerite> oh ha the bot isn't here
<infinisil> sphalerite: Feel free to open a new issue or post it in the existing one, doesn't matter :)
<infinisil> Or you can talk about it here too
<sphalerite> that said, I'm going to try nixus out because nixops not supporting multiple nixpkgs versions keeps being a pain.
<infinisil> Hehe, yeah the ability to just specify the nixpkgs in the config file is very neat
<infinisil> sphalerite: Hmm, so the immediate problem with your ideas is that currently Nixus works entirely on the Nix level. That is, it's just a Nix expression that builds a deploy script. You yourself can then run `nix-build` on that expression and call the deploy script
<infinisil> So Nixus doesn't control the nix-build invocation at all
<infinisil> currently at least
cole-h has quit [Quit: Goodbye]
cole-h has joined #nixus
<sphalerite> yeah
<sphalerite> I tried doing some funky stuff with drvPath in some deployment script attempts of my own, but it turns out that referencing a derivation via drvPath will introduce a reference that causes the derivation to be realised, and using unsafeDiscardStringContext will prevent the .drv from being created (iirc)
<infinisil> Oh yeah, I think I tried some drvPath stenanigans recently too
<sphalerite> IMHO keeping everything within a single expression isn't worth the restrictions it imposes on what the tool can do overall
<sphalerite> err
<sphalerite> well a single nix value %)
<infinisil> There's builtins.unsafeDiscardOutputDependency btw, which I think could get around the drvPath realisation problem
<sphalerite> oh boy.
<sphalerite> I think wrapping nix is nicer :p
<infinisil> Maybe the main Nixus eval can be kept to a single Nix expression, so that that can be used by people who don't need the extra features
<eyJhb> I really should try out Nixus as well
<eyJhb> Currently all my systems are just getting outdated little by little
<eyJhb> But the worst thing is, when I need to open a port real quick or just for a while. There is no good way of doing this, where you control the OS at remote (the configs), without building the config, pushing it, etc.
<sphalerite> eyJhb: yeah, I migrated from that setup to nixops a while back and it's a massive improvement
<eyJhb> Skipping the Nixops step and going straight to nixus seems like the way :D
<eyJhb> But does nixops solve the issue you have atm. sphalerite ?
<eyJhb> ALso, uni has started now... So my time.. So limited! :,(
<sphalerite> eyJhb: well no, having some hosts on unstable and others on stable doesn't work so well yet :)
<eyJhb> More the DSL thing
<sphalerite> oh right
<sphalerite> no, it doesn't, but it's not a huge problem because I don't have that much to upload
<sphalerite> (I do have deployment.hasFastConnection = false, which leads to the target hosts fetching from the cache where possible)
<eyJhb> Would such a option improve on this? - What connection do you have available as well? :D
<sphalerite> I'm confused by both of your questions :p
<infinisil> eyJhb: Fyi both nixops and nixus have a hasFastConnection option with the same behavior