Make component retrieval automatic

[ODiogoSilva]

Right now, components are added to flowcraft by including a nextflow template file and a python class with the attributes of that component. Then, we have a dictionary that maps the template and the class. This is cumbersome to maintain, as the dictionary is getting quite large with the addition of new components and we could improve on this.

By using a similar system to the recipes (see https://github.com/assemblerflow/flowcraft/blob/recipes/flowcraft/generator/recipe.py#L647), we could automate the "loading" of components into flowcraft by searching for all classes in one or more submodules. We can also extend this search to other paths, which would allow users to add new components locally without having to push them to flowcraft.

For this, we would need to:

• Create a loader function that gathers all classes in specified modules/paths
• Add a new attribute (e.g. name) to each class, containing the same key as in the current dictionary mapping.

[cimendes]

Totally agree! and this should be added to the road-map.

[tiagofilipe12]

Initial idea:

class ProgressiveMauve(Process):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)
        
        self.name = "mauve"

Currently a process should be made as follows:

class ProgressiveMauve(Process):
    def __init__(self, **kwargs):
        super().__init__(**kwargs)

However this will require that an argument is passed to the Process __init__ in order to instantiate it. However this assumes that we already know the template name, which we don't know before generating the process_map (which in turn is the whole purpose of this function).

As a suggestion we could do something like:

class ProgressiveMauve(Process):
    def __init__(self):
        super().__init__(template="mauve")

This will allow us to instantiate the class and fetch the template value to make a process_map dictionary internally without having it hard-coded in the engine.py.
Given that the Process class currently only accepts the template argument, the **kwards doesn't seem required to define each component class and with this suggestion we could easily fetch the template name to be used by each one of the components and generate the process_map internally.

[ODiogoSilva]

So, I tried a simpler approach that precludes the addition of a new attribute to the Process class and issues with instantiating the class without having the template name: 2b5df4b

The basic idea here, is that all classes inside the component class are retrieved and their name (which should be in CamelCase) is converter to snake_case, which is then used as the template name. This will mean that future component development will be a little bit easier, but we'll need to ensure that there is a match between the class name and the nextflow template file name.

[tiagofilipe12]

Yes, I like your proposal because it simplifies the construction of the component class but it needs to be very clear in the documentation how the correspondence is made (e.g. component class ILikeIt, and the nextflow template is something like i_like_it. However, it might be tempting to think that snake_make is something like lowercase but it has a slightly difference and that is why you changed FastQC component classs to Fastqc. But it should be fine, if well documented and otherwise the developers will not be able to test the build module anyway, it will retrieve an error message.