Global Plugin improperly loaded as Local when specified on command line

[MNBrod]

When I invoke ginga from the command line with the --plugins= option pointing to a Global Plugin, the ginga tries to instantiate the plugin as a local one, yielding the following error:

$> ginga --plugins=MyGlobalPlugin --loglevel=20 --stderr --log=./ginga.log

...

2024-02-14 14:29:53,923 | E | PluginManager.py:70 (load_plugin) | Failed to load plugin 'MyGlobalPlugin': __init__() takes 2 positional arguments but 3 were given
Traceback (most recent call last):
  File "/Users/mbrodheim/opt/anaconda3/envs/pypeit/lib/python3.9/site-packages/ginga/gw/PluginManager.py", line 55, in load_plugin
    obj = klass(self.fv, fitsimage)
TypeError: __init__() takes 2 positional arguments but 3 were given

This happens with my own plugin, as well as with the MyGlobalPlugin example copied from the documentation (as a side note, that example requires adjusting the import line from ginga.misc import Widgets to from ginga.gw import Widgets to run).

This occurs on ginga 4.1.1 from pip, as well as well as ginga 4.2.0.dev71+g1c3cd843 installed from source just now. I do not recall this happening with CLI invoked global plugins a few months ago the last time I did it, but I don't have a firm date on when that was.

Am I missing something obvious here? I feel like I must be...

[MNBrod]

All it took was writing up an issue to realize I was calling --plugins== and not --modules==.

Closing

[ejeschke]

You got it. You can also use options in your $HOME/.ginga/general.cfg. See "Customizing the set of plugins" here.

[ejeschke]

Probably a future version of ginga will be able to distinguish those two types with one parameter, the way --disable-plugins does now.