Update openlifu imports

[sadhana-r]

Before merging

• Merge P/init install cleanup openlifu-python#444
• Release new openlifu version and update python requirements

[sadhana-r]

@georgevigelette @alkagan Can you please test this branch with the hardware to confirm that the routing of signals works correctly?
This branch uses the re-organized openlifu library: https://github.com/OpenwaterHealth/openlifu-python/tree/p/init_install_cleanup, so you will have to re-intall the python requirements.

[ebrahimebrahim]

(Here is a package that can be used for testing if it is convenient to install from a package: 34046-linux-amd64-OpenLIFU-gitf078c02-2026-04-28.tar.gz)

[peterhollender]

@stahir715 can you grab the package and test that it communicates correctly with the device?

[peterhollender]

@sadhana-r I made some updates on a device plugged into a faulty console, which was great for checking the error handling, but still need to test on a good unit so I can run a sequence

[peterhollender]

@sadhana-r, @ebrahimebrahim are you opposed to killing off openlifu_lz here? I had another branch where I went through and replaced these with direct imports from openlifu, since part of the openlifu refactor was to reduce eager and circular import paths, and to introduce some native lazy importing of the heavier packages only when needed. I've rebased those changes off of this branch, and everything looks to be working - should I merge those changes into this branch, or is there another way to bring them in? Or are there other benefits to openlifu_lz I'm missing?

[ebrahimebrahim]

I think it's still useful to have openlifu_lz just for the sake of triggering install when openlifu itself is missing. So if a Slicer user installs the extension and goes to a random module, before they install the python requirements, they are met with a python install prompt rather than a nasty ImportError exception

[peterhollender]

I think it's still useful to have openlifu_lz just for the sake of triggering install when openlifu itself is missing. So if a Slicer user installs the extension and goes to a random module, before they install the python requirements, they are met with a python install prompt rather than a nasty ImportError exception

Huh, I didn't know it did that. The new requirements status display is great, though- maybe this functionality isn't needed anymore? I think the lz stuff makes the code a little confusing to read, since it has to do the type checking wizardry and the openlifu methods and classes are all imported from something other than openlifu.

[ebrahimebrahim]

I think the lz stuff makes the code a little confusing to read, since it has to do the type checking wizardry and the openlifu methods and classes are all imported from something other than openlifu.

I agree, it'd be nice not to have to deal with that.

We could switch to ordinary lazy imports, just plain import openlifu but only inside of functions when it's needed.
And then to avoid the problem if failed imports, we can stick the check-and-prompt-to-install into the enter or setup of each module. SO at least you see the prompt to install before you see the exception just from module entry.
@peterhollender is this close to the changes you had in mind?

In the next version of Slicer, we'll have this nice pip_ensure: https://slicer.readthedocs.io/en/latest/developer_guide/slicer.html#slicer.packaging.pip_ensure
which we can just stick above the lazy imports. That will be awesome because it will remove even the need to restart slicer -- it knows to check whether a restart is actually needed.
That is coming in the next month or so, as Slicer 5.12 comes out.

So for now I think just switching to lazy import openlifu, ditching openlifu_lz, and sticking the check-and-install into enter/setup is a good solution.

[peterhollender]

I think the lz stuff makes the code a little confusing to read, since it has to do the type checking wizardry and the openlifu methods and classes are all imported from something other than openlifu.

I agree, it'd be nice not to have to deal with that.

We could switch to ordinary lazy imports, just plain import openlifu but only inside of functions when it's needed. And then to avoid the problem if failed imports, we can stick the check-and-prompt-to-install into the enter or setup of each module. SO at least you see the prompt to install before you see the exception just from module entry. @peterhollender is this close to the changes you had in mind?

In the next version of Slicer, we'll have this nice pip_ensure: https://slicer.readthedocs.io/en/latest/developer_guide/slicer.html#slicer.packaging.pip_ensure which we can just stick above the lazy imports. That will be awesome because it will remove even the need to restart slicer -- it knows to check whether a restart is actually needed. That is coming in the next month or so, as Slicer 5.12 comes out.

So for now I think just switching to lazy import openlifu, ditching openlifu_lz, and sticking the check-and-install into enter/setup is a good solution.

Ah, that sounds like a nice middle route. Still using lazy importing to help with module initialization, but without the middle layer of the _lz class. Do you want to add that to my de-lz'ed branch? https://github.com/OpenwaterHealth/SlicerOpenLIFU/tree/p/streamline_openlifu

[ebrahimebrahim]

Do you want to add that to my de-lz'ed branch? https://github.com/OpenwaterHealth/SlicerOpenLIFU/tree/p/streamline_openlifu

Yes, I can add it there. Aiming to get to that this week

[ebrahimebrahim]

Actually @peterhollender, I think your de-lz'ed branch is likely to have a lot of conflicts with this one here. They will touch the same exact lines: the openlifu imports and usages of openlifu_lz.

This branch here is the more finnicky one that needs hardware testing, due to it dealing with the split out of openlifu-sdk from openlifu. So I think it makes sense to get this PR here integrated after a hardware (with a good unit).

Then I can redo the de-lz'ing work along the lines mentioned above. It shouldn't take long, it would be quicker than rebasing your branch and handling the conflicts.

Does that sound good?