<bqv>
execline is basically a decent programming language
<infinisil>
cole-h: Oh yeah that would be neat
<infinisil>
Wait does static nix work well with cross comp
<bqv>
hmm
<cole-h>
No clue
<cole-h>
Cross compilation is scary to me
<cole-h>
(Scary in that it's hard to get right)
<cole-h>
(And also I know nothing about it)
<bqv>
i suppose if it works and it's simple, sure, but how will things like e.g. the deployment script dag work, through haskell?
<infinisil>
Yeah, interaction with Nix might be tricky
<cole-h>
infinisil: I would like to say: thank you for making `nodes.<name>.configuration` able to use `imports = [];`
<infinisil>
:D
<cole-h>
The example in the repo has `nodes.<name>.configuration = ./configuration.nix` so I was worried I'd have to hard-code everything into my configuration.nix
<cole-h>
Happy that's not the case
<infinisil>
How do you mean hardcode?
<cole-h>
infinisil: Though one complaint is that I can't set "network"-wide nixpkgs to have a specific overlay and config.
<cole-h>
infinisil: Well, I broke some minor things out into my deployment.nix so I don't have to bring niv's `sources` into scope in configuration.nix when it's already being used in the deployment config
<infinisil>
cole-h: `default.configuration.nixpkgs.overlays = ...;` should work
<infinisil>
Well, it adds the overlay to all systems
<cole-h>
infinisil: I was hoping for something like `defaults = { ... }: { nixpkgs = sources.nixpkgs { overlays = ... }; }`
<infinisil>
I think this was discussed before, and we found problems with doing that
<infinisil>
Oh yeah, it would double-import nixpkgs
<infinisil>
Once by your code, and another time by nixos itself when it tries to apply nixpkgs.overlays and such
<cole-h>
infinisil: I see. Then, I guess default.configuration.nixpkgs.overlays will suffice :) Thanks.
<infinisil>
I mean it would be possible to implement a `pkgs` option, but it would be a bit wasteful, as essentially it would only use `pkgs.path` to set `nixpkgs`
<infinisil>
I don't think it could even propagate the overlays you already applied
<infinisil>
Maybe it could actually
<infinisil>
But yeah, it's a double nixpkgs import, which is a bit wasteful
<infinisil>
Might be something to look into though, maybe it's fixable
<infinisil>
E.g. I can imagine an option like `getPkgs = { overlays, config, system }: import sources.nixpkgs { overlays = [ your overlays ] ++ overlays; inherit config; inherit system; }`
<infinisil>
Though this wouldn't be any different than just setting the overlays with configuration.nixpkgs.overlays
<bqv>
see i just abused nixosConfigurations and got nixus to accept that as a config
<bqv>
infinisil: also goddamn it, my flake now literally depends on nixus for dag.nix
<bqv>
you better not get rid of that
<bqv>
i don't want sloppy thirds
cole-h has quit [Ping timeout: 258 seconds]
cole-h has joined #nixus
cole-h has quit [Quit: Goodbye]
<infinisil>
bqv: I think rycee also has the original dag code in a nur repo
<bqv>
Yeah, your consolidation was much nicer though
cole-h has joined #nixus
<bqv>
infinisil: so what were your thoughts on switching to execline scripts?
<bqv>
Make an s6-like infrastructurs
<infinisil>
s6?
<infinisil>
I haven't used execline at all, I just know that it's better than bash but similar in spirit
<infinisil>
The thing I mainly want from haskell is the abstractions, type safety and static compilation
<infinisil>
And I wouldn't expect execline to have anything like that
<bqv>
No, not at all
<bqv>
But I don't know how you can have that, with this hackable dag
<bqv>
I can't believe the words are coming out of my mouth, but, please don't rewrite this in haskell :p
<bqv>
It'll almost certainly mean it loses it's best feature
<infinisil>
bqv: The customizabilit?
<infinisil>
Of the phases?
<bqv>
Yeah
<infinisil>
Pretty sure that could still work
<bqv>
From inside nix?
<infinisil>
Yeah
<bqv>
How?
<infinisil>
Actually yeah that should still work
<infinisil>
Because the dag doesn't say anything about how its entries are used
<infinisil>
E.g. the final dag could be constructed in haskell
<infinisil>
Haskell just needs to know the entries you specified
<infinisil>
I didn't explain that well
<infinisil>
But I'm 99% sure it can work
<infinisil>
And I'd implement that
<infinisil>
Because it sure is nice to be able to just specify bash scripts :)
<infinisil>
Well I guess you might lose bash variables between phases, but that's probably a good thing
<bqv>
infinisil: you misunderstand me
<infinisil>
Oh?
<bqv>
I abuse the dag to edit the phases hardcoded in nixus
<infinisil>
Oh
<bqv>
Without having to edit nixus
<bqv>
Thats a luxury
<bqv>
And I like it
<infinisil>
For the `nix copy` thing?
<bqv>
For example, yes
<infinisil>
Hm I see
<bqv>
I wouldn't want to lose that power
<bqv>
But if parts are in haskell, I don't see how I wouldnt
* infinisil
thinks about that
<bqv>
A power of this is that its all bash, so all mutable
<infinisil>
If it's in haskell, there could be a whole deployment API you could use to write custom deploy phases or override predefined ones
<infinisil>
In haskell
<infinisil>
With type checking and everything
<bqv>
Then you have to compile something to deploy
<bqv>
That seems unpleasant
<infinisil>
You'll need to in any case if there's any haskell involved
<infinisil>
But unless you change phases every time, you won't have to recompile
<bqv>
I dunno. Honestly one of my favourite things about nixus as now, is that it doesn't bring in any binaries, in any language
<infinisil>
Hmm
<bqv>
I might fork it into my flake if you do haskellise it :p
<infinisil>
Yeah but I think there's a reason all these deployment solutions use some high-level language
<bqv>
I dunno about that, s6 showed that you don't need HLL for complex systems
<infinisil>
Frankly, I think nixus will be stuck with hacky deployment scripts forever unless some better language is used
<bqv>
Execline is just fine
<cole-h>
If you know and understand it
<infinisil>
^
<bqv>
Well you'd have to know haskell too
<bqv>
Execline is way simpler, frankly
<infinisil>
But also, I like how you can have a whole bunch of guarantees in haskell
<bqv>
It's just weirdly shaped bash
<infinisil>
Because of functional purity and such
<bqv>
Mm, I love purity, but I'm not fussed about it in this context
<bqv>
Especially with deployment being such a fundamentally impure operation
<infinisil>
That's an argument that could be said about anything
<cole-h>
Well, there's also the thing that infinisil already knows Haskell :P
<infinisil>
Because all haskell programs are fundamentally impure
<cole-h>
And likely doesn't know execline
<bqv>
I suppose.
<bqv>
cole-h: I learnt it in half a day, it really is just oddly shaped bash scripting :p
<infinisil>
Maybe there could be some input/output passing API between phases that's language independent
<infinisil>
Wait no
<infinisil>
But like maybe each phase could be an executable, and you can write arbitrarily many implementations in different languages for each phase
<infinisil>
This could allow writing different backends of deployers
<infinisil>
And nixus could have a haskell and a bash or execline backend, and bqv could maintain the latter :P
<bqv>
I'm not against that
<bqv>
Especially since the chaining would lend itself to execline
<infinisil>
Hm, maybe it should be structured rather as a set of base deployment phases. And you can switch between multiple sets of them
<infinisil>
But tbh, I feel like trying to support multiple backends like that would be pretty bad and limit how fast changes can be made
<infinisil>
And I'm not sure if that's worthwhile just because some people don't like having to compile some stuff
<bqv>
I mean, I'm happy to amicably fork, if you wanna go down the binaries route
<infinisil>
Especially with Nix, which allows automating all of this
<infinisil>
It would still be just a `nix-build` to build the deployment script btw, no `nixus` binary
<bqv>
I know, just, with nixos managing all it does with activation scripts without needing binaries, I feel nixus should be able to too
<infinisil>
NixOS activation scripts are a bunch simpler in spirit though
<infinisil>
They don't have to coordinate multiple machines
<infinisil>
Or handle rollbacks
<infinisil>
Or handle any kind of cancellation
<cole-h>
I can understand the lack of enthusiasm for Haskell, because of the few times I've had to build things from source due to a cache miss for some reason or another.
<bqv>
I don't think any of that is complex enough to warrant formal verification or anything, like I say, if s6 can happily coordinate an entire system of services, I reckon nixus would be ok
<infinisil>
cole-h: Hm yeah, I guess a cachix cache would be needed to prevent that
<bqv>
(fv: exaggeration for comical effect)
<cole-h>
infinisil: But how would a cachix cache help those customized phases? ;)
<infinisil>
cole-h: That of course not yeah
<cole-h>
I can certainly see both sides of the story.
<infinisil>
I'm just already sick of bash
<infinisil>
And there's so many features I'd like to add
<infinisil>
It's so hacky already
<bqv>
I can understand that, at least
<infinisil>
And there's a bunch of issues with it too
<infinisil>
And I don't believe execline would be a reasonable improvement
<infinisil>
s/reasonable/substantial
<bqv>
I think it would, from my experience of it. I'm actually quite interested to see how it'd look with this, so I may try it anyway
<bqv>
Not gonna fork or anything, just, I might fiddle a bit in spare time and see how far I get
<infinisil>
bqv: Can you link to some s6 execline script that shows it off a bit?
<infinisil>
Or just any somewhat complicated execline script
<bqv>
I'll have to get out of bed for that, bear with me
<infinisil>
Hehe
<infinisil>
bqv: Ohh! Crazy idea: Use an effect system in Haskell that allows multiple implementations, one of which could be an implementation that *outputs* a bash/execline script to do the work
<infinisil>
So Haskell could be used to *generate* a bash/execline script during CI or so
<infinisil>
This allows the abstractions, but also doesn't incur any compilation on users
<bqv>
also, i'm also not against that, i suppose. because fundamentally that wouldn't affect my situation, it'd just mean the bash isn't hardcoded in your repo, but it's still there
<bqv>
and still hackable
<bqv>
the whole skarlibs ethic is do use tiny composable scripts, so that's why there's no large bodies anywhere
<infinisil>
bqv: Got a link to a specific script file that's a bit longer?
<infinisil>
Having a hard time finding anything interesting
<infinisil>
Oh
<infinisil>
Only just now read your last message
<bqv>
that's kinda by design, you know. what i mentioned above, but also that's enforced by the fact that the argv buffer of exec calls is limited to 256 or whatever, so execline scripts can't be miles long
<bqv>
they're self-policing :p
<infinisil>
Damn
<bqv>
they can be longer than those, just not aeons long
<infinisil>
Well, I guess I still don't really have any clue about execline then
<bqv>
i think one in my repo is already longer than that
<bqv>
like i said, i'll have a play around, see if i can demo you what i have in mind using nixus
<bqv>
perhaps that'll be easier
<infinisil>
Sounds good
<infinisil>
While I think there's 0 chance of me pushing execline to nixus, it would still be interesting to see :P
<infinisil>
It's also kind of a matter of popularity, which will help with contributions. And execline is terrible regarding that
<bqv>
could say the same for haskell :p
<infinisil>
Many Nix people are familiar with Haskell though, so it's not too bad!
<bqv>
popularity is no mark of decency, imo
<bqv>
heh
<infinisil>
Yeah for sure, less-popular things can and are often better than more popular things
<infinisil>
Oh and this bash-generating idea also gets rid of any cross comp issues
<infinisil>
The only question is then whether it's possible to have this work in any satisfactory way
<infinisil>
Because it would probably be pretty limited what you can generate