Open philipstarkey opened 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.
Original report (archived issue) by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).
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
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.