0

I'm designing a command line tool and I'd like to implement a Plugin feature.

The idea would be that upon startup, the tool scans all packages in its current virtualenv and lists all classes that inherit from a specific base class (say foo.BasePlugin).

I found easily how to get the list of installed modules but I have no idea how to list the classes for each listed package/distribution.

Is there a way to list all defined classes in all modules of the current virtualenv ?

Community
  • 1
  • 1
ereOn
  • 48,328
  • 33
  • 147
  • 228
  • Duplicate of http://stackoverflow.com/questions/739993/how-can-i-get-a-list-of-locally-installed-python-modules?lq=1 ? – SylvainD Mar 12 '15 at 17:34
  • @Josay: Not really: I don't only want to list modules but to extract all classes definitions from them. Also that's the answer I link to in my question. ;) – ereOn Mar 12 '15 at 17:35
  • 1
    Wouldn't it be easier to make `BasePlugin` itself store a list of all subclasses? – jonrsharpe Mar 12 '15 at 17:41
  • @jonrsharpe: Plugins can be implemented by anybody at anytime. The goal is to detect all subclasses that might be currently accessible in the execution virtualenv. Perhaps I should make that more clear in the question. – ereOn Mar 12 '15 at 17:44
  • 1
    It's certainly possible via combinations of [`inspect`](https://docs.python.org/2/library/inspect.html) methods, combined with the information from your linked answer. But it's going to be very slow to scan every single installed python module, enumerate every class, and check them for properties (this could be *millions* of classes). Is there a reason you can't make some form of registry, or have modules which implement your plugin have to include a file (XML or the like) in their package declaring their plugin classes? – aruisdante Mar 12 '15 at 17:45
  • I don't think asking plugin authors to conform to one of the many plugin mechanisms is too much. – Ignacio Vazquez-Abrams Mar 12 '15 at 17:46
  • In other words, most plugin systems I've ever worked with require at least *some* work from the plugin implementer to integrate with the system (installing in a specific folder, or modifying a specific manifest, etc). It's generally impractical (nor is it usually a good idea) to assume that any piece of code anywhere could be a potential plugin. – aruisdante Mar 12 '15 at 17:48
  • @aruisdante: Actually the initial writing of my question was mentionning the fact this would likely be slow and asked for alternatives. I removed it because it made the question too broad (and I knew someone would come up with that suggestion anyway). Having plugin authors include a file to their package is perfectly acceptable but how do I get that information back ? – ereOn Mar 12 '15 at 17:48
  • You should look at Marty Alchin's post on implementing a [plugin framework](http://martyalchin.com/2008/jan/10/simple-plugin-framework/). – Daniel Roseman Mar 12 '15 at 17:52
  • @DanielRoseman: Interesting read. Thanks. However that works well for a library/framework but less for a command-line tool. – ereOn Mar 12 '15 at 17:56

0 Answers0