Separation or renaming of ConfigModels

[gubaidulinvadim]

Description, motivation and use case
Right now, the ConfigModel is kept in the same file as the actual class with implementation. This is nice to keep everything in the same place. However, when writing the script without a config file, there is a small issue when ConfigModels are imported. One needs to do

from something.something.bpm import ConfigModel as BPMConfigModel
from something.something.quadrupole import Config Model as QuadrupoleConfigModel

Is it required for the Factory to have for everyclass a ConfigModel and not a SomethingConfigModel? I imagine it is easier with ConfigModel for everything in the same file. But it should be possible to modify it.

Proposed solution
Either we need to rename All ConfigModels or put the configuration in a separate place

Example
Something like below should be possible

from something.something import BPMConfigModel, QuadrupoleConfigModel

This technically only reduces the lines of code by one. But I find it to be much better personally.

Additional context
@TeresiaOlsson was mentioning this same issue some time ago.

Checklist

• I've assigned this issue to a project
• I've @-mentioned relevant people
• I've checked, there are no duplicate issues

[TeresiaOlsson]

I'm in favour of unique names. The documentation also becomes complicated to understand if there are several classes with the same name.

Personally I also don't like that the config model is used to initialize a device object. That also makes the documentation difficult to understand because you need to look at a different class to understand what the input should be. I have an idea in mind where every class would explicitly define which input it needs and the config model is just used to validate the data. So validation is separated from object creation.

I have an idea for this that I'm working on but I didn't have time to finish it because of workshop preparations. I want to refactor the factory because I would like at some point in the future to be able to use the same config to initialize devices for our IDs and connect the work our ID group is doing on measuring feedforward tables to pyAML. But that development is bluesky using ophyd devices which means the factory needs to be sufficently general to also create objects from external packages.

Next week I will get back to working on the idea I have for how it could be done.