Distribution plan for common interface definition in IVI Python driver spec

[lw370481]

The document states that Python drivers shall implement the IviUtility (and IviDirectIo, ErrorQuery) abstract base class (ABC) and expose it via an ivi_utility property on the root driver class. However, I haven’t seen any information about how the IviUtility class definition will be distributed or made available to driver developers.
Since this interface is shared across all Python IVI drivers, it seems important to have a consistent and central definition.
In other programming languages (like C#), we have a shared assembly distributed by the consortium, ensuring that all vendors implement the same interface version.
Do we have a plan for how the IviUtility interface will be deployed or distributed? Is there any intention to publish it as an official PyPI package for vendors to depend on? Or will each vendor copy the interface definition into their own driver package?

[joseph-mueller]

Thanks for the comment! This needs further discussion by the working group.

Couple of approaches that seem reasonable to me:

1. I think an easy light-weight solution would be to just include the source code to the ABC in the specification (this is what I was anticipating when I wrote the draft). I think because of EUCRA and other issues we probably want to avoid publishing shared components for Python. One light-weight approach to this would be to post the source code alongside the spec -- the Core spec has some key elements in files that are alongside the main spec. If we conclude that dilutes the spec process too much, we could also put the code in an appendix. As written, I think almost all of the content is inline within the spec, but it might be more convenient to have it separated out.

2. Perhaps in Python the ABC is not strictly needed and we can just rely on the duck-typing. But we are still relying on the API definitions in the draft.

I think there is an orthogonal question of if we need a true ABC, or if we can just publish the API.

[bkeryan]

How about using structural typing? The spec could define a IviUtility as a typing.Protocol and say that the driver's class must implement that protocol.

https://peps.python.org/pep-0544/

[nfelt14]

I think I had heard the idea of including it as an appendix. I like that idea since it would allow the entire ABC to be provided as a single file that could be copied. Attributes required could be marked as abstract, and recommended things could just be left in as non-abstract with comments.

As a driver creator, that file would be very helpful in making sure that the driver is compliant.

[joseph-mueller]

Just a comment on the appendix idea --- to me an appendix is like a chapter in the document, so it could be easily extracted from the spec (and is automatically ratified/updated with the spec). However, it is not really a single file that can be copied.

Having said that, I am mildly inclined towards the appendix approach (or just put it inline in the spec) so we do not have to worry about spec process.

I guess at the same time I would check in, alongside the spec, a usable Python file with the ABC from the appendix. Then anyone building a driver could just use that file, but IVI does not have the onus of having to spread the strict IVI driver definition across two files. The file would have to start with appropriate disclaimers that it is an implementation based on version X (1.0) of the spec and IVI makes to guarantees, etc etc....

[Miloslav-RS]

We will agree on a code to share during the spec approval process, since the spec approval does not depend on it.

[joseph-mueller]

This is in process with the approach of adding a file alongside the spec without rearranging the spec to have an appendix (maximum spec clarity and file is available for users). Therefore I am closing the discussion.