I'm not sure I'm totally fond of this type of override. Why not go with the usual with<Plugin> scheme? I.e withVtwheel or withResizefont?

I pretty much stole this design from the weechat package. You can see it in the nixpkgs manual It's a little verbose but it's completely configurable.

withVtwheel would require some kind of code generation or hard-coding a few combinations of plugins.

On the same note of my confusion below, I tend to think it will be better... EDIT: if it'll end up as a matter of postInstall and + lib.optional it will be easy to do what ever a user may wish with an override such as:

postInstall = oldAttrs.postInstall + ''
  # shell code here
''

Whatever the override scheme will go like eventually, I would like this part to list the required Perl / other dependencies for each plugin. The plugin I packaged once - bidi, requires fribidi.

If a plugin is perl module simply adding it to the plugins should just work because its closure already contains all the dependencies.
perlDeps is meant to add some perl modules you may need if you are testing/working on a custom plugin (not installed but somewhere in ~)

Oh right I'm confused, why are there also plugins, perlDeps, and extraDeps if any given derivation which has a file in it's $out/lib/urxvt/perl/ will pull all of it's needed dependencies if added to plugins? It seems overly complicated now.

BTW 1 more thing I've noticed is that urxvt_bidi, the plugin I contributed in the past, is generally a normal perl module, the only thing it has relevant for urxvt is just another file that is installed with postInstall, see:

https://github.com/rnhmjoj/nixpkgs/blob/16c22b01b5e706cc0e3b5371ae5409977e618ed8/pkgs/applications/misc/rxvt-unicode-plugins/urxvt-bidi/default.nix#L15-L17

Yet in the old plugins configuration system, it needed to be added also to perlDeps in addition to plugins... I'm just trying to understand what makes it an exception and perhaps we could overcome this. Perhaps putting the external dependency fribidi (which was the original trouble maker) to propagatedBuildInputs might help?

Oh right I'm confused, why are there also plugins, perlDeps, and extraDeps if any given derivation which has a file in it's $out/lib/urxvt/perl/ will pull all of it's needed dependencies if added to plugins? It seems overly complicated now.

I've rephrased the explanation I give in the manual and added two examples. I hope it's clear now. The idea is basically:

• plugins: to add urxvt plugins
• extraDeps: to add any kind of package that it's not specifically a plugin to the wrapper
• perlDeps: to add Perl packages/modules so that you can use them in your plugins, which are not packaged in nixpkgs but are in ~/.urxvt/ext

BTW 1 more thing I've noticed is that urxvt_bidi

What's special about urxvt_bidi is that it's a Perl package (you built it with buildPerlPackage) and that it needs to be added to the PERL5LIB path. Other plugins are simple Perl scripts that urxvt looks for in the URXVT_PERL_LIB path.

On the same note as in the comment just above this, It'd be nice if another paragraph will kindly ask packagers to document the required dependencies for their plugin, if needed.

@rnhmjoj Could you please take care of this suggestion?

If you mean documenting dependecies of the user, I don't think there will be any need: with this method users don't have to worry about them. All a package author has to do is to specify the the dependencies like in any other derivation (buildInputs, patching shebangs, whatever..). The only special case I can think of is urxvt-bidi, which requires setting a special value in the .passthru to signal it depends on the perl module it self provides.

O.K, nice :) Feel free to mark this conversation and the others as resolved.