Original report (archived issue) by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
After PR #79, there is the possibility that BLACS will not work correctly with a remote worker due to the two running incompatible versions of BLACS.
Providing strict backward compatibility is likely more effort than it's worth, but we need a way to at least identify the situation and tell the user about it so that they can upgrade BLACS on the affected machine.
To that end, BLACS workers should have a check_version method that calls labscript_utils.check_version to inspect the versions of arbitrary modules/components. BLACS should call it upon worker startup to ensure that BLACS itself is new enough, catching the AttributeError if the remote version is old enough that it doesn't even have the check_version method yet. It should then raise an error prompting the user to upgrade BLACS on the remote machine to the appropriate minimum version.
The method can then later be used to enforce version requirements of individual labscript devices - though before we do that, labscript_utils.check_version will need to learn to look at __version__ attributes of arbitrary submodules (right now it only looks at top-level modules, since it tries to determine versions from package metadata rather than actually importing modules).
Note that the error message from check_version, if it raises an exception, should be wrapped to say that the error happened on the remote computer, otherwise it can be quite confusing for the user, who won't be able to tell which machine the error applies to.
This should be implemented before the next release. Once this issue is migrated to github, we should add this issue to a release milestone.
Original report (archived issue) by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
After PR #79, there is the possibility that BLACS will not work correctly with a remote worker due to the two running incompatible versions of BLACS.
Providing strict backward compatibility is likely more effort than it's worth, but we need a way to at least identify the situation and tell the user about it so that they can upgrade BLACS on the affected machine.
To that end, BLACS workers should have a
check_versionmethod that callslabscript_utils.check_versionto inspect the versions of arbitrary modules/components. BLACS should call it upon worker startup to ensure that BLACS itself is new enough, catching the AttributeError if the remote version is old enough that it doesn't even have thecheck_versionmethod yet. It should then raise an error prompting the user to upgrade BLACS on the remote machine to the appropriate minimum version.The method can then later be used to enforce version requirements of individual labscript devices - though before we do that,
labscript_utils.check_versionwill need to learn to look at__version__attributes of arbitrary submodules (right now it only looks at top-level modules, since it tries to determine versions from package metadata rather than actually importing modules).Note that the error message from
check_version, if it raises an exception, should be wrapped to say that the error happened on the remote computer, otherwise it can be quite confusing for the user, who won't be able to tell which machine the error applies to.This should be implemented before the next release. Once this issue is migrated to github, we should add this issue to a release milestone.