Faux import

[multimeric]

Another, simpler attempt at #448.

The logic behind this is that omero.model imports classes from omero_model_XXX but type checkers can't understand this because it's done dynamically. If we put the imports into a if TYPE_CHECKING guard, it won't run at runtime but type checkers will at least understand the link.

This approach still lacks actual type annotations, but to solve this we could need to address #469 and/or zeroc-ice/ice#4264.

Mypy probably still won't like this, because there are a lot of other type issues including the fact it can't statically analyse the parent class relationships which requires zeroc-ice/ice#4265. Still, this should be an improvement because you can list and navigate to the class definitions in VS Code:

The pylance server also seems to understand which methods the class has:

But it doesn't understand instance methods because of zeroc-ice/ice#4265.

[multimeric]

Actually you can fix the above error by adding a tiny Ice stub:

$ cat typings/Ice/Ice.pyi

from typing import Any

def openModule(module: str) -> Any: ...

In theory this should be fixed upstream in Ice, but we're using 3.6 so any upstream changes won't reach us anyway.

[pepone]

Would you be able to upgrade to Ice 3.8, which targets Python 3.12 and above, once it is released?

[multimeric]

That's an interesting question, and probably the best solution here. I'll open another issue.

[sbesson]

@pepone from a maintenance perspective, we are aware that Ice will need to be upgraded at some stage. From previous experiences, we are arguably talking of the most challenging OMERO dependency. The complexity here is that the impact of the library upgrade goes way beyond the scope of OMERO.py as similar changes will need to be applied to OMERO server as well as every OMERO client. Practically, we are talking of a backwards-incompatible change affecting the whole OMERO ecosystem associated with a significant amount of scoping, work and coordination both on the development & testing as well as the deployment side. At present, there is no plan for such an effort by the OME & Glencoe Software teams.

Specifically for OMERO.py, the Python 3.12+ requirement for Ice 3.8 is another concern as it is more restrictive than the minimal requirement for this library which is currently Python 3.9+, probably moving to 3.10+ later in the year as Python 3.9 goes officially EOL.

[joshmoore]

Since omero-py wouldn't be installed with Ice>3.6 for the moment, would it be safe to ship typings/Ice/Ice.pyi here?

[multimeric]

No, that file couldn't be included in omero-py, I believe we can only include type stubs for our own package. The solution I suggest above is for the end user to create a typings stub folder in each project that uses omero-py.

Another option is to move all the type annotations into a separate stub-only package which I believe could include Ice stubs as well. This has the added benefit of allowing .pyi files for all the top-level OMERO models too, meaning that we get actual types and not just method autocompletion. The downside is that its no longer co-located or maintained together with omero-py.

[jburel]

@joshmoore is this PR and #450 on your radar?

[multimeric]

I suppose an alternative to this PR is for users to just import the models directly from their "true" location. ie instead of:

from omero import gateway, model
gateway.DatasetWrapper(conn, model.DatasetI())

You can do the following, which type checkers can better understand:

from omero import gateway
from omero_model_DatasetI import DatasetI

gateway.DatasetWrapper(conn, DatasetI())