weechat: add NixOS module #33523
weechat: add NixOS module #33523
Conversation
| users.weechat = { | ||
| createHome = true; | ||
| group = "weechat"; | ||
| home = cfg.root; |
There was a problem hiding this comment.
I should configure my Emacs to not do that. Thanks.
| systemd.paths.weechat-fifo = { | ||
| pathConfig = { | ||
| PathExists = "${cfg.root}/weechat_fifo"; | ||
| Unit = "weechat-apply-init.service"; |
| serviceConfig = { | ||
| Type = "oneshot"; | ||
| User = "weechat"; | ||
| Group = "weechat"; |
| }; | ||
|
|
||
| config = mkIf cfg.enable { | ||
| users = { |
There was a problem hiding this comment.
I commonly come across shell-hosts that offer a bunch of weechat sessions (usually one per person, user, …).
Would you think it could make sense to refactor this to allow multiple weechat sessions per host?
There was a problem hiding this comment.
There are quite a few NixOS services that could benefit from running multiple copies. Tor, for example, is one of them, if someone is running an exit node and has multiple IPv4 addresses, it would make sense to run one instance of Tor per IPv4 address.
I think this should be implemented through containers rather than by adding complexity to each service that might benefit from this.
There was a problem hiding this comment.
Good point. Probably a sensible thing to do then 👍
| User = "weechat"; | ||
| Group = "weechat"; | ||
| }; | ||
| script = "exec ${pkgs.screen}/bin/screen -D -m ${pkgs.weechat}/bin/weechat"; |
There was a problem hiding this comment.
The use of screen is probably opinionated as is the usage of tmux. I personally prefer tmux.
Do you think adding an option (defaulted to screen) would be sensible?
There was a problem hiding this comment.
tmux doesn't work here. Also, I'm not happy about this workaround, and I don't think that it should be a part of public API.
There was a problem hiding this comment.
I think screen is fine for now given the use case for this module. Not sure if you can attach to a running screen or tmux session without some hackery anyway. ;)
There was a problem hiding this comment.
Ideally, Weechat should be patched so that this hack is not required. It would be enough to strip ncurses initialization and run weechat without printing anything to terminal.
lukateras
force-pushed
the
20180106.130747/nixos-weechat
branch
2 times, most recently
from
a38273c
to
c549fd4
Compare
lukateras
force-pushed
the
20180106.130747/nixos-weechat
branch
from
c549fd4
to
ab2f4eb
Compare
|
this looks cool, what keeps us from merging ATM (and is there anything I could do?) |
|
@Ma27 I probably have stalled it with my discussion. Sorry for that. @yegortimoshenko Can you rebase this and merge? |
|
It would be also nice if we had ACME support but it will be ugly without weechat/weechat#757 |
|
@jtojnar Using nginx as proxy with the websocket support works pretty well for me. Even the Android app supports that. :) |
|
I think the static uid/gid is not strictly needed, right? This would also resolve the merge conflict that's currently prevents merging this. :) |
|
@fpletz except the removal of the static uid/gid there's nothing else to change, right? |
|
If I understand the policy about static uids ( 8c3503d ) then weechat qualifies. |
|
this can be closed IMHO, the actual idea of adding a service which runs weechat in a screen has been implemented and merged to master. |
|
Closing; obviously if I'm wrong, just re-open :). |
Motivation for this change
Mainly for use with Glowing Bear or any other Weechat frontends, i.e. as an IRC relay/bouncer.
Things done
build-use-sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)