I think it'd be more convenient to pass the plugins as names instead, which would then add whatever packages are necessary. Otherwise, the user needs to know which python package set to use, which packages to add and so on.

Also, I think it's cleaner to rely on the list itself to carry information about whether to enable plugins than to use a separate parameter.

Then again, discoverability is so poor that it almost makes no difference ...

@joachifm Thanks for your thoughts.
I'm also not sure what an elegant way would be or if there should just be one package with all plugins. However, imho it would be nice to limit the amount of unnecessary (and perhaps fishy) plugins to a minimum.

One possibility is

packageOverrides = super: {
  electrum = super.electrum.override { plugins = [ "foo" "bar" ]; };
}

and in the package expression do

{ plugins ? [ ], ... }:
let
  pluginPackages = { "foo" = [ package1 package2 ]; ... };
  # ...
in
# ...
buildPythonApplication rec {
   # ...
   buildInputs = [ /* ... */ ] ++ concatMap (x: getAttr x pluginPackages) plugins;
   # ...
}

But I think it's simpler to just provide a default batteries included variant and a minimal variant, where the former is derived from the latter by passing additional build inputs via override.

Are plugins always Python packages? And does a plugin require/constitute an individual package (with dependencies) or multiple independent packages?

You have to make sure Python plugins/packages are build using the same interpreter as the rest of the package. You could solve this with using a lambda:

{ ...
, python
, plugins = (ps: with ps; [ keepkey trezor ])
}

let
  p = plugins python.pkgs;
in {
...
... + p;
}

At the same, there should ideally be the possibility to use plugins that are not yet part of python.pkgs. But that can be done by overriding the Python package set.

Finally, don't over-engineer this :)