Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
Identified in 8887e1f697 (r239097413).
9504292b1e accidentally reverted all the
changes that had been made to the weechat wrapper since
8887e1f697.
I removed the wrapper, then wrote it again, but this time taking the
code from the latest version of weechat before the bad merge.
Allows for adding Perl libraries in the same way as for Python. Doesn't
really need to be a function, since there's only one perlPackages in
nixpkgs, but I went for consistency with the python plugin.
Loading olm.lua as weechat script with `/script load olm.lua' causes
errors like this:
```
/nix/store/43jbh7yxh8j4gjfzbvpd9clncah5dip1-weechat-matrix-bridge-2018-05-29/lib/ffi.so: undefined symbol: lua_tointeger
```
As `olm.lua' is loaded by `matrix.lua' it doesn't need to be included
manually by the weechat configuration.
In my previous PR I missed that ${sec.foobar} (syntax to retrieve
secrets in a weechat runtime) breaks the shell evaluation.
Furthermore `;` shall be used rather than `\n` to concat scripts and the
init config.
This aims to make the `weechat` package even more configurable. It
allows to specify scripts and commands using the `configure` function
inside a `weechat.override` expression.
The package can be configured like this:
```
with import <nixpkgs> { };
weechat.override {
plugins = { availablePlugins, ... }: {
plugins = builtins.attrValues availablePlugins;
init = ''
/set foo bar
/server add freenode chat.freenode.org
'';
scripts = [ "/path/to/script.py" ];
};
}
```
All commands are passed to `weechat --run-command "/set foo bar;/server ..."`.
The `plugins' attribute is not necessarily required anymore, if it's
sufficient to add `init' commands, the `plugins' will be
`builtins.attrValues availablePlugins' by default.
Additionally the result contains `weechat` and `weechat-headless`
(introduced in WeeChat 2.1) now.
If I have a patch I want to apply to weechat, I can't do that with
overrideAttrs like I can with almost every other package, because that
only applies to the wrapper derivation. For other wrapped packages, one
can usually call the wrapper with any version of the derivation, but the
weechat derivation didn't expose a wrapper creation function.
Taking inspiration from other packages, particularly Firefox, I
extracted the wrapper into its own function, made the default weechat
derivation use that, and added weechat-unwrapped.
Now I can add my custom patch like this:
(wrapWeechat
(weechat-unwrapped.overrideAttrs (oldAttrs: {
patches = [
(fetchpatch {
url = "55767f5f11.patch?full_index=1";
sha256 = "1pkcdsby57diqds1y5hhl0fr4i8j0zax32jb0gqd36siki3lza3d";
})
];
}))
{ configure =
{ availablePlugins, ... }:
{
plugins = with availablePlugins; [
(python.withPackages (packages: with packages; [ potr websocket_client ]))
];
};
})
There is a small backward incompatibility here: previously, it was
possible to get an unwrapped weechat like this:
weechat.override { configure = null; }
This didn't seem too important to keep around since it was also possible
to get an unwrapped weechat in a much more obvious way:
weechat.unwrapped
I could probably make it so that the first way still worked, if that
behavior turns out to really have been important.
Also add a wrapper generator that allows adding the plugins back
conveniently and corresponding documentation in the package notes
section of the nixpkgs manual.
They're still enabled by default, but now can be disabled.
Python has not been made optional due to the additional complexity of:
- python2 vs python3
- pync support on Darwin
Making Python support optional should be revisited at another time.
This reverts commit cd52c04456 and
others.
Managing certificates (including revoking certificates and adding
custom certificates) becomes extremely painful if every package in the
system potentially depends on a different copy of cacert. Also, it
makes updating cacert rather expensive.
make it easily possible to extend current buildInputs using override function.
eg.:
weechat.override { extraBuildInputs = [ pythonPackages.pync ]; }
i've removed pync since its plugin dependency which can now be added via
extraBuildInputs.
