Move the barion efficiency into a plugin

[kakaroto]

The barion efficiency formula would benefit from being its own plugin, now with the new plugin system, it would be nice to even allow one plugin (rune extractor) to use other plugins to extend its functionality (add a new csv column).
I'm thinking plugins would have access to the plugins list, and we could use a csv.DictWriter, and plugins could have the method :

def process_csv_row(row, type, data)
    row['new_column'] = 'value'
    return row

where 'type' argument would be 'rune' or 'monster' or 'friend_rune', or 'scenario_run',etc.. these could be anything that the plugin that creates a CSV wants it to be (they'd need to be unique among plugins), and 'data' argument would be specific to the plugin, so for example 'rune' type would have a rune dictionary as 'data', etc...

[fperegrinvs]

Assuming that each plugin have only one very specific role, we can categorize plugins according to the entry point so we can proper filter them using yapsy built-in methods.

Some plugins will need multiple entry points but not every plugin would implement all methods. Should we just check if method exists as suggested here or should we pursue something more fancy and elegant ?.

[kakaroto]

oh, I'd say we'd have a class SWPlugin which inherits IPlugin. and SW plugins would derive from that. That class would implement all functions with a 'pass' so plugins can overwrite the function if they want to implement it, otherwise the base class's function will be called, which will be a noop.
EDIT: I just saw the link you posted. That's interesting, we could indeed have categories that implement CSVParser vs. JSONParser, but I don't think it's necessary, add filters, check category, it gets even more complicated if a plugin needs to do both..

[kakaroto]

I like how you did the csv_type + data_type. Great idea. Merged and fixed, so I'll close this issue. thanks!