Merging Eapii in Lantz

[MatthieuDartiailh]

I will list here all the things we need to do when merging Eapii in Lantz, we can discuss more specific points in other issues :

• make Lantz base class free from Qt, and solve th issue of signal handling.
• incorporate Eapii notions of Subsystem and Channel
• move from Feature and Processors to Eapii IProperty system, while adding logging (do we need timing)

The previous two could nearly be handled backwards by integrating Lantz features into Eapii (I for one would find it easier, mainly would mean handling logging and update, refresh methods)

• adapt Action to handle not using Processors (might tweak Eapii base meta class to handle it too)
• if possible make a single signature init for subclass drivers (see Eapii)
• split the ui part into its own package

Once all those core issues will be tackled we will be able to start porting drivers and adding new ones.

[JesterEE]

I looked up Eapii and see there are only 2 drivers available for it. So the following questions must be asked.

1. Why should Lantz undergo all your marked changes to support 2 pieces of equipment instead of just writing 2 Lantz drivers?
2. Does Eapii offer something that Lantz doesn't that would warrant such a merge?

It seems like your asking the author of this package to adopt all of Eapii's conventions. It doesn't seem all that logical to me.

[hgrecco]

@JesterEE Thanks for your concern, I do think that is a question must be asked and I would like to give a detailed answer. I actually asked @MatthieuDartiailh to open this issue to start discussing a few ideas in the open.

First, let me say that Lantz 0.3 is going to be released as discussed in the mailing list including all new cool things such as Backend and Frontend classes, the MessageBasedDriver class, blocks for GUI building, etc.

Having said that, let me tell you the idea (Sorry, but is long!)

Lantz was originally conceived as a 3 part project:

Lantz-core: Helpers to build instrument drivers including the base classes for different instruments types, Feat, Action, etc. With a small number of requirements so that it can be used in simple scripts and/or limited environments. Changing slowly.

Lantz-gui: Helpers to build user interfaces. Require Lantz-core and Qt and can be used to be build more sophisticated apps.

Lantz-drivers: Classes for different instruments. Requires Lantz-core. Updated frequently.

I decided to start putting the three parts together as in the beginning there is a LOT of co-evolution, but as things began to stabilize it make sense to do the splitting. As a small comment, this does not mean that it would change for the normal user that wants the full thing. It is convenient for the development and for the special users.

Qt was never meant to be a requirement of the Core. I actually decided not to use Traits to avoid complex libraries. For limitations during the development, we had to cut some corners and after a long struggle, Qt became a requirement used by Driver, the main class of the core. (Previously, it was optional leading to code very difficult to maintain.) I was never happy with this decision. In complex apps, I want to have the power of using Drivers as QObjects (threading, signals, etc) without needing for simple scripts.

If we are able to achieve this, is a big WIN for Lantz. And this was the plan way before Eapii appeared.

Now, going really to the merging issues asides Qt.

I think that the notions of subsystem and channel is missing in Lantz. The DictFeat is useful, but limited to certain cases. In the past there were some discussion about how to build instruments consisting in multiple instruments, I think this nails it. So I would say this is not a change but rather a feature that is being add to Lantz

Lantz use the notion of Processors: which are functions that the user can write to be applied before and after fetching the value. There are few processors provided by Lantz to map values, check units, enforce limits, etc. And they are also used by Lantz under the hood when you build a Feat. This is very flexible and works well. But I have never seen somebody writing a processor themselves. If they need to pre- or post process the value they rewrite the getter or setter. In my opinion, this means that the API for this case is not good.

The idea is not to remove the Feat and Action but to change the implementation for one that does the same thing in a different way, easier to maintain and to extend by pre_ and pos_ hooks.

Still, all of this are discussion points. So I think this issue can be a meta discussion and then start opening other to discuss each issue independently.

Finally I would like to say that Python is great for instrumentation. But its usage needs to grow. This will only happen if the tools get better. We need to join efforts and reach consensus to do it, putting egos aside. Of course a single person project is easier to manage: I very rarely think differently of myself :-). But I think that what we need is a sustainable project that grows to fulfill the needs of many. And the way is to have a community of users and developers around it.

That is why the Lantz repository will soon be moved out of my account to an Organization account named LabPy. @MatthieuDartiailh is joining LabPy, putting a lot of effort to incorporate the best ideas of Eapii (and also new ones) into Lantz. Hopefully others will join.

[MatthieuDartiailh]

Sorry about the wording. Having written Eapii only a while ago after thinking a lot about the structure I am biased towards the way I did things. I hope that @hgrecco answered most of your concerns. Actually I planned to add a whole bunch of other driver (see HQCMeas project, instrument folders) but I lacked time to port them to Eapii. So now I will focus on Lantz and port them when both @hgrecco and myself are satisfied with our work.

[hgrecco]

The repo has been migrated to LabPy. We can start moving things

One crazy idea here, not settled in stone but to think about. I was looking at enaml which I think is the only real reason to stay in Python 2.X (please correct me if I am wrong). It seems to me that Atom is almost Python 3 compatible and that this is the heaviest dependency of enaml. If this is really the case, wouldn't make sense to work directly in Python 3 and hope (or contribute) that enaml is Python 3 compatible by the time Lantz 0.4 is ready. It seem to me that the effort to write Python2/3 compatible code would be best put someplace else.

[MatthieuDartiailh]

The issue is that I need a working Lantz to move ahead with HQCMeas and even if Enaml is Python 3 compatible in six months given the size of my project I won't be able to do the switching in just a knack of my fingers. So I really needs python 2 support (it has also been mentioned as something worthy in #python-ivi 23)

[hgrecco]

I see. I have no problem then. Let's do it Python2.7/3.2+ ok?