What is the process to load this module into weechat?

I opened this PR because I always try to contribute the Nix expressions I built back to the ecosystem if possible.
My current approach is unfortunately quite crappy (simple nix-build --out-link), however I wanted to try building something based on a FHS environment as it's possible to modify the home dir of weechat (default to ~/.weechat) which contains the plugins, but needs to be writable.

If I manage to build something usable, I'll submit another PR :-)

btw the travis error seems quite unrelated. I shouldupdate my local nixpkgs, however this might delay until I have better wifi :p

@fpletz I created the following gist which contains the expression I'm currently using: https://gist.github.com/Ma27/153a2bd1089c284671d0018508c9c66e

Would appreciate it if we could discuss about it, when we found a suitable solution for nixpkgs, I'll submit a PR :-)

Thanks!

@Ma27 This is really interesting! Do you think this is or could be compatible with this WeeChat plugin system pull request: #25274 ? It would be nice to be able to load these plugins easily in WeeChat.

@jluttine didn't have a deeper look into it, but yeah, I've planned to give it a try as soon as #25274 is merged.

@Ma27 I see that #25274 is merged now. Is there some way to build weechat with this plugin included?

Unfortunately not with this patch directly.

There's a difference between plugins and scripts in weechat and since weechat/weechat#971 it's now possible to search for plugins at multiple locations, e.g. ~/.weechat and a store path which bundles several plugins.
I currently work around this with a module that links everything into a single directory (https://gitlab.com/Ma27/nur-packages/blob/master/modules/weechat.nix#L95), however it's definetely a better solution to patch weechat accordingly (which I still have to at some time)

You might want to use symlinkJoin for that. Otherwise I don't think the solution is inherently bad. Its pretty much the same thing python does. Any reason you haven't upstreamed those changes yet? They should even be backwards compatible if you do get around to make the change in weechat right?

You might want to use symlinkJoin for that

Care to elaborate? Weechat stores all of its data (except plugins since #25274) in ~/.weechat which is writable and can't be a store path.
If you reference to my (admittedly hacky) module, I didn't do this to keep the directories writable. When I add a simple script to test it, I don't want to have a readonly store path, but a writable directory with linked scripts (at least for now).

Any reason you haven't upstreamed those changes yet?

When I started working on this, it was just some crazy late-night experiment that was far too opinionated. It became a bit more usable for normal people, but I'm still not sufficiently confident to submit it to nixpkgs upstream, since I still dislike the manual configuration of files like irc.conf or weechat.conf. Many scripts store their defaults in such files, having them read-only makes the setup significantly harder.

Furthermore I'm not sure if this is the way to go. In fact, there's #33523 which also uses screen to allow weechat running on a different machine and access it via ssh.
It allows to configure using /cmd foobar through Nix (didn't know how to implement this some months ago 😅 ), however this is the better solution IMHO.
Regarding the scripts I'd prefer to implement a better resolution approach upstream which allows multiple directories to search for scripts, then we may have an even better approach for a declarative weechat configuration.

Until then I'd use my weechat module, but I'd much rather reserve some time in the next months to implement it right for upstream :)