Add openlifu version check and installation button in login module

[sadhana-r]

Closes #544

• The install python requirements button is always enabled.
• The button text updates to indicate whether openlifu is installed, and what version is required
• If openlifu is not installed, entering the login module will prompt the user automatically to install openlifu since it is required for initializing default user accounts.
• If openlifu is installed, but is not the latest version, the user is not automatically prompted to update openlifu, but the button and status icon indicate that the latest version is not installed.

Todo:

• Confirm that the changes to the user account settings don't break things in the custom app.

[ebrahimebrahim]

This looks great to me! It works very well

I agree that we should check that nothing broke int he custom app before merging.

BTW did the login module always import openlifu on entry? That creates a situation where you can never validly get to the install button in the first place if you didn't already have some version of openlifu installed.

[ebrahimebrahim]

I am thinking about what would happen when someone puts a git+... sort of requirement for openlifu, as we often do while testing unreleased versions of openlifu. I think it's okay to not support version checking in those cases, since they are debug cases, but should the version check auto-pass or auto-fail? Right now I think it autopasses because this would return None. Maybe that is fine, just brinign up the question.

[sadhana-r]

Good point - I didn't consder that situation. You're right, right now it auto-passes so the user isn't notified that a dev version needs to be installed. Currently the version check only fails if openlifu is not installed or it is the wrong released version.

I'm going to push a commit that handles the dev situation such that it auto-fails/notifies the user - it's an easy check and doesn't break anything else.

While testing this, I noticed that there is potentially an issue in the current main branch of openlifu (OpenwaterHealth/openlifu-python@9f17b94). When installed, openlifu.util.assets is not recognized. But I didn't get this error with an older commit (pre v0.18). Do you mind testing it on your end?

[ebrahimebrahim]

BTW did the login module always import openlifu on entry? That creates a situation where you can never validly get to the install button in the first place if you didn't already have some version of openlifu installed.

Below is a suggested fix from a claude conversion, which I think I agree with but see if you think there's an issue ... there are few cases to consider: no openlifu, openlifu but no database, database but no users in it, ....

We can do it in this PR or we can do it later, all fine.
Just raising this now because we are sticking the install button into the login module in this PR; it may make sense to eliminate the circularity.

(ai generated content)

Here's the issue and proposed fix:

Problem: OpenLIFULogin.setup() calls _initDefaultUsers() which calls openlifu_lz() to create User objects. This triggers the install prompt before the user can reach the Home module's install button — a catch-22.

Proposed fix: Lazy-init the default users. Skip _initDefaultUsers() in setup() when openlifu isn't installed, and add a guard method:

def _ensureDefaultUsers(self):
    if self._default_anonymous_user is None and python_requirements_exist():
        self._initDefaultUsers()

Call _ensureDefaultUsers() at the start of methods that use the default users (updateWidgetLoginState, logout, onUserAccountModeClicked, onDatabaseChanged). In setup(), wrap the relevant lines:

if python_requirements_exist():
    self._initDefaultUsers()
    self.logic.active_user = self._default_anonymous_user

This is safe because before openlifu is installed, there's no database and no login — the default users serve no purpose. Once the user installs openlifu via Home and navigates back or connects a database, _ensureDefaultUsers() will initialize them on demand.

For the custom app, openlifu is always bundled so this path doesn't apply. If desired, the custom app could add an early fatal error if openlifu isn't importable, rather than silently breaking.

[sadhana-r]

I agree that we should check that nothing broke int he custom app before merging.

Custom app seems to work as expected

[sadhana-r]

BTW did the login module always import openlifu on entry? That creates a situation where you can never validly get to the install button in the first place if you didn't already have some version of openlifu installed.

Yes, this has always been the case! Before it was in the __init__ function of the login module so
couldn't even load the module without installing openlifu. But it hasn't really been an issue because the user is automatically prompted to install openlifu as soon as they open the module. So there was never a sitation where you are in the login module, with openlifu not installed.

The claude suggested fix works well for handling the default users, but I realized the other issue is that OpenLIFUSonicationControlLogic's init function calls openlifu_lz() (for lifu interface related functions) and the login module currently initializes all of the moduels in self.cacheAllLoginRelatedWidgets().

So we need to either make changes to the sonication control module to avoid openlifu dependency at startup or the login module should not cache the sonication control module if openlifu isn't installed. perhaps better to do this in a separate PR?

[ebrahimebrahim]

The claude suggested fix works well for handling the default users, but I realized the other issue is that OpenLIFUSonicationControlLogic's init function calls openlifu_lz() (for lifu interface related functions) and the login module currently initializes all of the moduels in self.cacheAllLoginRelatedWidgets().

So we need to either make changes to the sonication control module to avoid openlifu dependency at startup or the login module should not cache the sonication control module if openlifu isn't installed. perhaps better to do this in a separate PR?

Yes, agreed, a separate PR. We can put it off indefinitely for now ... it is good that we have a clear explanation of the problem and possible solutions recorded here

[ebrahimebrahim]

Looks great! One small change and we should be good to merge

[ebrahimebrahim]

Suggested change

	return installed_hash.startswith(required_hash)
	return required_hash.startswith(installed_hash) or installed_hash.startswith(required_hash)

One might be shorter than the other which would make startswith fail; a symmetric comparison like this removes the worry

(commit hashes get truncated to various lengths by various tools/conventions)