Visidata: [wishlist] Load plugins without requiring any changes in a .visidatarc

Created on 24 Apr 2020  路  5Comments  路  Source: saulpw/visidata

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.

plugin wish granted

Most helpful comment

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

All 5 comments

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
Was this page helpful?
0 / 5 - 0 ratings