Right now, a user needs to add:
from plugins import *
to their ~/.visidatarc in order for plugins to load.
Note, that we should load the ~/.visidatarc first. That way if there is an error loading a plugin, the user's options will still successfully be set.
Not to balloon this before it gets started, but I have a feeling this might need to involve a bigger rethink on how plugins are being loaded.
In PR #503 I migrated a new set of loaders out of native Visidata into a plugin, and didn't do any testing of it being loaded via the plugin bazaar as I'm running nixos and didn't want to start troubleshooting pip as well :/
However, this means that in order to load the plugin, I had to add the line from plugins.generic_sql import * to my .visidatarc since from plugins import * didn't work. I don't know if that's unique to generic_sql since I'm exporting openurl_* functions that need to be accessible as globals or if it's because I'm not exposing those function properly or if its because I installed the plugin manually.
I looked a bit at the code in plugins.py and saw that by default plugins are being imported with a import <pluginname> statement. I only have passing familiarity with python's import system but would there need to be work done to make that import process more flexible?
Hey @aswan89!
In PR #503 I migrated a new set of loaders out of native Visidata into a plugin, and didn't do any testing of it being loaded via the plugin bazaar as I'm running nixos and didn't want to start troubleshooting pip as well :/
We are really hoping to approach this with: https://github.com/saulpw/visidata/issues/448
And yes, I think these two issues are going to be related.
Right now code in ~/.visidata is actually not being actively imported. What you are seeing is the import statements being written into ~/.visidata/plugins/__init__.py. Folks then can import that into their ~/.visidatarc. Yes, there will need to be work done to make that more flexible.
I really appreciate you writing out all this feedback for us. It will be helpful when we decide how to approach this.
How about options.imports, a space-separated list of modules to import at startup directly into the global namespace, that defaults to 'plugins'?
@saulpw Mmmmmm....I like that a lot.
This should be fixed with ee766919ddbe96aefaa5942ea206020efa8f9207.
[cli] add --imports (default "plugins")
- space-separated list of modules to import into globals before loading .visidatarc
- effectively does "from <module> import *" for each module
- default allows plugins to be installed by VisiData without modifying .visidatarc
Most helpful comment
This should be fixed with ee766919ddbe96aefaa5942ea206020efa8f9207.