search

labscript-suite-temp / labscript_utils

Shared modules used by the labscript suite. Includes a graphical exception handler, debug tools, configuration management, cross platform filepath conversions, unit conversions and custom GUI widgets.
Other
0 stars 0 forks source link

win32 dependency has a minimum requirement #1

Open philipstarkey opened 10 years ago

philipstarkey commented 10 years ago

Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: pstarkey).

In the dual species BEC lab at Monash University, we are running the EPD 7.0.2 (32-bit) Python 2.7.1 distribution. This came with the win32 library.

When starting runmanager (and presumably other programs) the following exception was raised

#!python

Traceback (most recent call last):
  File "C:\pythonlib\runmanager\__main__.py", line 101, in set_win_appusermodel
    set_appusermodel(window_id, appids['runmanager'], icon_path, relaunch_command, relaunch_display_name)
  File "C:\pythonlib\labscript_utils\winshell\__init__.py", line 56, in set_appusermodel
    store = propsys.SHGetPropertyStoreForWindow(window_id, propsys.IID_IPropertyStore)
AttributeError: 'module' object has no attribute 'SHGetPropertyStoreForWindow'

Upgrading win32 to build 219 (from sourceforge) made the exception go away. Presumably there is a minimum version requirement for the win32 python wrapper. Unfortunately I couldn't see an easy way to find the version number from the win32 library (but I didn't try very hard).

We should probably try and include some sort of version check on this dependency.

philipstarkey commented 10 years ago

Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).

(Completely obtuse) method of getting version number is here:

http://stackoverflow.com/questions/4093041/programmatically-find-the-installed-version-of-pywin32

I'll add in the version check to the winshell submodule, and I haven't totally decided how or whether to do version checking in the installer (since individual programs have their own version requirements - it might be better to leave this to runtime and only check that modules are importable at install time - which is what I'm presently doing)

It looks like the functionality in question was commited on 2012-07-24 and first included in build 218, released on 2012-10-29. So it's probably near saturation in the wild and we just had an old install.

Enthought Python Distribution (now called Enthought Canopy) presently comes with 218, Anaconda I'm not sure but it obviously worked there (since that's what I was developing on). So we're probably fine but I'll put the check in anyway.