I think this is a good idea @mnjowe

Agreed - this would be a nice feature to add. I think how the module dependencies are already declared could already allow doing this on the presumption that there is only one subclass of Module with a particular name (for example that there aren't two Lifestyle classes defined in different Python module files) which at the moment is the case, though having a more explicit specification of where the class is defined would definitely be more robust and easier to work with. Specificlly the get_module_class_map helper function in src/tlo/dependencies.py

I think we would probably want to make this behaviour opt-in, at least initially, rather than the default so we could so somehting like add a keyword argument auto_register_modules defaulting to False to the Simulation.register method and if it is True find any missing dependencies and add them to the list of modules to be registered. This would only allow registering modules with the default values for their __init__ method arguments, but for a lot of cases this would probably suffice. One slight snag is that at the moment all modules have a required positional argument resourcefilepath to their __init__ method so we would either need to add this as an additional optional argument to Simulation.register to be passed through, or, refactor so that resourcefilepath is instead defined at the Simulation level as an argument to its initialiser (with modules then either given access by setting an attribute when registering or exposing a property which uses the existing reference to the top-level simulation object).

Thanks so much @matt-graham for the detailed explanation on how we can go about this. Should I then in a few days open a new PR on this?

Yeah opening a PR on this would be great! I would potentially try to deal with the issue of setting resourcefilepath for each module in one PR and have a separate PR for adding a new keyword argument to Simulation.register that allows automatically loading dependencies. The former is likely to require a bit more figuring out of what interface we want to go with and how to do this in a backwards compatible manner, and will also potentially involve edits to all existing modules, so might be a bit more complex to orchestrate.

To avoiding delaying a PR on adding the automatic module registering, for now we could potentially assume something like that automatically loaded dependencies are initialised with the resourcefilepath attribute of the already loaded module which they are a dependency for? This is a bit brittle as there is nothing which currently enforces that modules define a resourcefilepath attribute but would mean if we later refactor this so it is for example defined at a simulation level, we don't need to make multiple changes to the Simulation.register interface.

Great, thanks @matt-graham . The two issues you have noted above are indeed so important in as far resolving this automatic module registering issue is concerned. Especially the resource file path which is needed when registering disease modules. I think I will have to delay my PR on this until you have found a workaround on the resource file issue. Thanks

Thanks @matt-graham and @mnjowe

You're both quite right about the 'resourcefilepath' thing.

I do think that we can assume that the resourcefilepath is the same for all modules, and in fact, is really a Simulation-level parameter.

Indeed, I think there is already a structure for this, that we should have been using all along (I think I am to blame for not using it!): The place where the data is read-in is always Module::read_parameters, which is passed an argument from the Simulation object data_folder. I assume data_folder is intended to be a path to the resources that was provided to the Simulation on initialisation.