Package organisation

[MatthieuDartiailh]

• Not a major question but how should we organize this package ?

  I would be in favour of organizing by vendor independently of the underlying protocol (ie visa, a dll, another python library).

• A secondary question is what to do with hp/agilent/keysight instruments and other similar stuff ?

• Third point as the metaclass magic can increase the lodaing time of the drivers it might be interesting to know all the existing drivers without having to import everything, and import only when the user needs a specific driver. I would love to have such a feature as when building uis I need to propose all existing drivers to my user but I like my app to start fast.

[hgrecco]

I think by vendor is the organization that we all have reached in our packages. One package/folder per vendor is the right way to go.

They only way to address the third point is to have summary file with the most important information. This could be easily done automatically with script that the developer should run (or linked to a commit hook)

[MatthieuDartiailh]

Ok so we agree about teh general organisation. I guess automating the third point is the easiest way to go, we will to thing about it.
So only remains the case of a single incrstrument existing under two vendor names (I have microwave sources which are agilent or keysight according to when they were bought). We could implement the driver in one vendor and create a dummy subclass in the other folder that is perhaps the easiest solution.

[alexforencich]

Storing by vendor sounds like the consensus. Seems like some form of automation would be a good idea.

As for multiple vendor names, that is a bit more problematic. One method would be to just list everything under the current vendor name and hope it doesn't change again (sigh...HP->Agilent->Keyshite->???). Another method might be to list items under the original brand only (originally HP -> list under HP, even if there are Agilent branded units as well). Or we could do that and then create an alias of some sort under the current brand as well.

[hgrecco]

I prefer to have it named as it is seen in the device. The rationale is that a person that is standing in front of an instrument can directly find the right driver without knowing the history of the company.

If the same device is then sold with another brand/model then we just create an new python file importing the original class with the new name (in a new packages).

[alexforencich]

What about file naming? For common base classes that are used by multiple drivers, I suggest storing these in a folder called 'common'. I think the driver dev branch has 'standards' right now, but that to me indicates something along the lines of calibration standards or something along those lines and not driver components. Thoughts?

For instrument models, it is common to start with a number (e.g. 8340A), which is a no-no for a Python module name. So what is the most reasonable solution for that? I think duplicating the manufacturer name makes sense (e.g. lantz_drivers.agilent.agilent_8340A), but adding some other standard prefix may also make sense (e.g. lantz_drivers.agilent.model_8340A). Whatever we do should be a standard though, so any prefix applied would also be attached to things that don't start with a number - so you would get things like lantz_drivers.agilent.agilent_DSA91304A or lantz_drivers.agilent.model_DSA91304A. What about capitalization and delimiters? All lowercase with an underscore (agilent_dsa91304a), lowercase with uppercase model number with or without underscore (agilent_DSA91304A or agilentDSA91304A) or something else?

Also, is there a clean solution to move the actual driver object up one level in the hierarchy? As in, it would be nice to be able to import lantz_drivers.agilent.agilent_8340A and use that directly instead of having to import lantz_drivers.agilent.agilent_8340A.agilent_8340A or lantz_drivers.agilent.agilent_8340A.driver or similar. In python-ivi, this was done by importing all of the classes in the parent init.py, but this is rather tedious.

[hgrecco]

The convention that we had until previous version of Lantz is the following:

1. One folder for each company
2. The folder is a (sub)package, contains and init file which imports and exposes ALL the driver classes in the package. (This can be done manually or automated)
3. The classes are named according to the module using Python PEP8. When the model starts with a number, we prefix with the first letter of the company. I am fine to choose another (short) prefix.
4. The number of modules in the package is really dependent on what makes sense for the company.

[alexforencich]

If we can come up with a simple way to automate the import process, that would be great. However, it seems to me that the current setup is to only import things explicitly and not to import whole trees. I'm not sure how this would map on to importing all driver modules in init.py files.

I think adding prefixes in a non-consistent manner is not such a good idea. It would not be difficult to imagine a company releasing some products with numeric models, and some that happen to be prefixed with a single letter that happens to be the same as the first letter in the company name. Keysight has quite a few products with part numbers like this - Exxxx, Bxxxx, Nxxxx, Uxxxx, etc. There is no Kxxxx right now, but if they do release something like that in the future it could conflict with something that has a pure numeric model number.

[MatthieuDartiailh]

I agree with @alexforencich about the prefix issue we should be consistent.

I am not a big fan of importing whole subtrees as I fear that the metaclasses magic will slow down the import. We could perhaps simply have factories in init.py with nested imports.

[alexforencich]

Well, if you know how to write said factories, then that sounds like it could be the most reasonable option.

Let's figure out the prefixes so I can start writing some drivers. We're throwing a couple of undergrads at this over here at UCSD, so it would be nice if we can get these last few blocking kinks worked out soon.

[hgrecco]

I think that we are over-engineering. Most instrumentation applications last long enough so that the import time is negligible. And we can always optimize that later. I think the important thing is to provide a convenient way, which in my opinion is:

from lantz_drivers.company import driverclass

and not:

from lantz_drivers.company.module import driverclass

This requires just importing the driver classes into the company __init__.py, which is something that you write just once and if that is very tedious you can just write a script to do it for you.

Regarding the prefixes. I am fine to use Model as in Model8340A.

[MatthieuDartiailh]

My point with factory would be to have :

def GS200(*args, **kwargs):
    from . gs200 import GS200
    return GS200 (*args, **kwags)

Which we could also automatize.

But I am not sure it is true good idea.

[MatthieuDartiailh]

I am fine with model as a prefix.

[hgrecco]

My suggestion is that we can always do it later. Let's first do it in the most straightforward manner, we can always drop your solution later (which is fine for me) without any backwards compatibility problem.

Having said this, I think a better idea for the future can be something like the following in lantz_drivers/__init__.py

def get_driver_class(manufacturer, model):
     # here we look into a YAML or json  file with a tree structure, for example:
     #    agilent:
     #       8340A: lantz_drivers.agilent.somemodule.Model8340A
     #
     # This file is kept in sync with a commit hook, but you can also build upon installation

     return driver_class # which is imported according to the YAML/JSON file

I played in the past with this option and was really nice as you could easily have a single driver (without any alias classes) for whole bunch of devices that are basically the same. The import performance is really good because it only reads lantz_drivers/__init__.py and the YAML/JSON file. The drivers are really imported on demand. In any case, I think this can be done latter.

[alexforencich]

I think Model is OK when an instrument starts with a number, but it seems awkward to me when it doesn't. For example, Model8340A and ModelMSO7104A vs. Agilent8340A and AgilentMSO7104A.