Would be nice to separate out devIocStats

[thomascobb]

In #5 we build devIocStats into the extension module as builder.py calls registerRecordDeviceDrivers which needs all .so files to be loaded beforehand. It would be nice to separate this out into another Python module, but this would be a backwards incompatible change

[thomascobb]

Or at least make it optional

[Araneidae]

What would be required to make it possible to include miscellaneous other EPICS support modules from within pythonIoc?

[thomascobb]

Basically we would need a devIocStats module on PyPI. We would probably package them as DSOs using setuptools-dso, with a little bit of Python (like epicscorelibs.path). I think we could make it so they weren't dependant on pythonIoc.

I have some concerns about going down this route:

• Each module would need their EPICS build systems duplicated into setup.py. I can't see a nice way of avoiding this duplication. Ideally we could put this into the module itself, but that requires negotiation with the module owner
• How would the databases be loaded? devIocStats database is read then added to the epicsdbbuilder.recordset. Other modules may use dbLoadDatabase. This might make it more difficult to work out how to use each module and leads to fragmentation of documentation
• We end up making a parallel IOC delivery system. If you can pip install devIocStats asyn streamDevice then you could deploy IOCs managed by pip. Do we want to do this? If not, we need to decide where to draw the line.

@mdavidsaver may have some thoughts on this

[thomascobb]

Also, we have to make sure that all .sos (packaged either as dsos or Python extensions) are loaded before calling iocshRegisterCommon(). This is currently done during import of softioc so either we would have to import devIocStats before import softioc (which seems fragile), or defer iocshRegisterCommon and the loading of dbds until the first record is created with softioc.builder (which needs the dbds loaded).

[mdavidsaver]

Keep in mind that iocshRegisterCommon() runs registrar functions, which is typically when support modules register new iocsh functions.

[Araneidae]

@coretl, @AlexanderWells-diamond, would like to discuss this in more detail and decide whether to come up with a way to proceed or definitely say we're not doing this.

[coretl]

Our conclusion was that it is too much effort in the wrong direction to make pythonSoftIOC a packaging tool for other support modules. Our preferred approach is:

• Replace devIocStats dependency with python device support implementing the same record interface #106
• Add an example pythonSoftIOC talking to a TCP device #107
• Demonstrate a record-level alternative motor interface #108

These decisions limit pythonSoftIOC to its core strengths (python logic between simple records) rather than trying to implement every kind of IOC that can already be made using support modules like streamDevice, asyn and motor.

I'm going to close this issue and replace it with 3 issues for the items above.