Move data interpretation to pymosa

[themperek]

Make data interpretation part from https://github.com/SiLab-Bonn/pyBAR_mimosa26_interpreter to pymosa

[laborleben]

I'd keep it separate. Other packages depend on it (e.g., testbeam-analysis). You can rename it. But why bother?

[themperek]

To keep everything in one place, tested (with unit tests) and in sync.
Testbeam analysis can import pymosa.
Same for #7

To be discussed.

[laborleben]

The interpreter is not part of pymosa IMHO. And should stay separated because it is shared between projects. I don't like the idea to install basil, pymosa, and all the dependencies, etc. just to get testbeam-analysis running.

[themperek]

You need to install: pyBAR_mimosa26_interpreter what difference it makes if you have to install pymosa instead?

The gain is it better tested, will have a package and will be in one place.

[laborleben]

One part is analysis software, the other one is hardware related. I would not mix them up. And as I pointed out it is not only pymosa, but instead many (hardware related) dependencies which come automatically if you do a pip install. This is useless stuff if you need the interpreter only.

[laborleben]

The tests can be in added to the Mimosa26 interpreter project. Anything speaks against it?

[DavidLP]

The reverse is also true: if you just want to take data and use another TB-system (e.g. Eudaq) you do not want to be forced to install beasty packages like numba. Although these issues can be solved by specifying pip install options for subpackages. But that is also messy to my mind,

[laborleben]

Please, no subpackages.

[themperek]

https://github.com/SiLab-Bonn/pyBAR_mimosa26_interpreter/blob/master/requirements.txt

numba can be done optional (use if you have not use if you have not)

[YannickDieter]

What is now the status? Should we move the new mimosa26 interpreteter to pymosa?
I would also be in favor to move it to pymosa. It is still separated and people only need to install pymosa to use our M26 stuff.

I am almost done with it, apart from some documentation for the interpreter which is definetly needed since it is a very complex thing which should be documented.

[laborleben]

I still would keep it separate.

1. No need to change subsequent packages that require pyBAR_mimosa26_interpreter. Would you like to break all existing installations/dependencies? Do you update all branches of other packages?
2. Keep the interpreter separate from Mimosa26 readout since they depend on different base packages. How would you separate the requirements (especially basil_daq) without programming sub-packages (as @DavidLP pointed out)?
3. Less clutter when distributing newer versions of the Mimosa26 interpreter. Do you want to distribute the whole pymosa package with firmware (almost 20MB alone for that), configuration files, etc., just to distribute fixes of the Mimosa26 interpreter (which has a few kB)? Believe me, you will have plenty of fixes and new features in the near future. Have a look at the current git history of the Mimosa26 interpreter or the FEI4 interpreter.

Yes, pyBAR_mimosa26_interpreter is not the best name since it is in wide use. But you will have much less work if you keep the packages separate - at least for some time.

[laborleben]

PS: A good time for merging both projects would be the time when we do the transition to Python 3.x.

[DavidLP]

Just for your info: With EUDAQ integration we have to do data analysis during data taking, thus this package has to depend on the interpretation package.

[YannickDieter]

I am so far done with the new (cleanup of Tokos code) Mimosa26 interpreter. You can see it here.
As soon as possible I will write a documentation and explain how to use the interpreter and how the event building is done.