One of the great things about perceval is that it is very extensible, allowing developers to write their own python library, and install it alongside perceval to extend functionality. This means that there's already plenty of 3rd party perceval plugins that can easily extend its functionality.
Unfortunately, as of right now, the only way to get a 3rd party backend to be processed with grimoirelab-elk is by forking the project to add it to the list of supported backends. This not only means a much greater burden for the developers, it also means that anyone trying to use two or more 3rd party backends at once would have to manually merge all of the forks they want to use.
If this sort of change would be accepted, I'd love to write up a pull request to allow grimoirelab-elk the same kind of modularity that perceval has. This would hopefully allow future backends to be supported by 3rd party, and would let users with a niche backend needing support to easily implement their own.
I'd imagine an implementation would involve replacing get_connectors() with an implementation a lot like perceval's find_backends(), and adding an additional class attribute to each backend module consisting of the backend name as a string, plus all of the classes currently listed in the get_connectors() method.
What are your thoughts about this feature, and do you agree with that way of implementing it?
One of the great things about perceval is that it is very extensible, allowing developers to write their own python library, and install it alongside perceval to extend functionality. This means that there's already plenty of 3rd party perceval plugins that can easily extend its functionality.
Unfortunately, as of right now, the only way to get a 3rd party backend to be processed with grimoirelab-elk is by forking the project to add it to the list of supported backends. This not only means a much greater burden for the developers, it also means that anyone trying to use two or more 3rd party backends at once would have to manually merge all of the forks they want to use.
If this sort of change would be accepted, I'd love to write up a pull request to allow grimoirelab-elk the same kind of modularity that perceval has. This would hopefully allow future backends to be supported by 3rd party, and would let users with a niche backend needing support to easily implement their own.
I'd imagine an implementation would involve replacing
get_connectors()
with an implementation a lot like perceval'sfind_backends()
, and adding an additional class attribute to each backend module consisting of the backend name as a string, plus all of the classes currently listed in theget_connectors()
method.What are your thoughts about this feature, and do you agree with that way of implementing it?
― Emi