IOSvc: Minor fixes for improving usage and errors

[jmcarcell]

BEGINRELEASENOTES

• Fail if IOSvc or ApplicationMgr are not imported with from k4FWCore import IOSvc (it can be imported from Configurables). The python wrapper in k4FWCore does a few minor things and importing from Configurables doesn't fail currently and can lead to hard to solve issues.
• Add an error message when reading a file without the events category. Currently it fails with an error in python that is not very clear.
• Use Input and Output for IOSvc, deprecate input and output since all the other properties are capitalized. The same for IOType instead of ioType. This will print a warning about a duplicated property that should be ignored for now.
• Suppress two warnings about using external input when using the default EventLoopMgr.
• Import ApplicationMgr always from k4FWCore

ENDRELEASENOTES

The two warnings are these:

EventLoopMgr      WARNING Unable to locate service "EventSelector"
EventLoopMgr      WARNING No events will be processed from external input.

they will appear always and this feature is not being used. In any case, this only overrides the default case, someone can create an EventLoopMgr and have the warnings. I opened an issue in Gaudi.

The most important is failing when importing ApplicationMgr from Configurables as most of the examples do not set the algorithms for reading and writing that the user doesn't need to worry about in almost any case, but the wrapper in k4FWCore does so one only needs to specify IOSvc.Input or IOSvc.Output.

[jmcarcell]

This should be ready to be merged. I will merge today if there aren't any comments.

[m-fila]

This should be changed to .Input and .Output too, no?

k4FWCore/test/k4FWCoreTest/options/runFunctionalMix.py

Lines 69 to 71 in 005dd3e

	iosvc = IOSvc("IOSvc")
	iosvc.input = "functional_producer_multiple.root"
	iosvc.output = "functional_mix_iosvc.root"

[m-fila]

If think it might be simpler if we say to just always import ApplicationMgr from k4FWCore rather than if there is IOSvc then import from k4FWCore otherwise import from k4FWCore or Configurables.

In a similar vain maybe all the examples could import from k4FWCore rather than importing from Configurables when possible?

Maybe in a longer run we could port our custom python wrappers (ApplicationMgr.py, IOSvc.py) back to C++ (no extra checks or python parsing needed on our side, users can import all they need from Configurables, easier to extend by users if needed)

[jmcarcell]

If think it might be simpler if we say to just always import ApplicationMgr from k4FWCore rather than if there is IOSvc then import from k4FWCore otherwise import from k4FWCore or Configurables.

In a similar vain maybe all the examples could import from k4FWCore rather than importing from Configurables when possible?

I agree this is a good idea and now all the examples import from k4FWCore.

Maybe in a longer run we could port our custom python wrappers (ApplicationMgr.py, IOSvc.py) back to C++ (no extra checks or python parsing needed on our side, users can import all they need from Configurables, easier to extend by users if needed)

About this I'm not sure, for ApplicationMgr that would require a reimplementation of the Gaudi one in C++ and then it can't be called ApplicationMgr anymore since there will always be already one available...