Had a quick view at the problem and considered several approaches.
Problematic code is::
if sys.platform == 'win32':
# Fix for paths with spaces on Windows.
# See https://bugs.launchpad.net/grok/+bug/315223
import win32api # <-- might fail
eggs_dir = win32api.GetShortPathName(eggs_dir)
Possible solutions:
1) Get rid of win32 import and compute the path ourselves:
Looks like this is not easily possible. The 8.3-path created by GetShortPathName() is apparently different on different
win32 platforms. There is no publicly available algorithm, just a bunch of guesses that _might_ work on _some_
platforms. No solid way thanks to proprietary code :-/ Maurits' solution (https://bugs.launchpad.net/grok/+bug/315223)
seems to be the correct one.
2) Install win32 on-the-fly:
Maybe this is possible but it would require very complicated extra-actions. Unfortunately the error happens at a place
where we have no buildout environment available. Looks like a no-opt to me.
3) Provide win32 binaries with pywin32 included (distutils bdist_wininst).
Might work, but requires a lot more effort on releases. Furthermore there seem to be problems on some platforms with
distutils bdist_wininst. Not sure, whether resultung dists would work in virtual envs as well.
4) Just check on startup, whether we run on win32 and if so, whether win32 is installed. If not, abort with a sensitive
error message, telling the user how to install pywin32.
Had a quick view at the problem and considered several approaches.
Problematic code is::
if sys.platform == 'win32': /bugs.launchpad .net/grok/ +bug/315223 GetShortPathNam e(eggs_ dir)
# Fix for paths with spaces on Windows.
# See https:/
import win32api # <-- might fail
eggs_dir = win32api.
Possible solutions:
1) Get rid of win32 import and compute the path ourselves:
Looks like this is not easily possible. The 8.3-path created by GetShortPathName() is apparently different on different /bugs.launchpad .net/grok/ +bug/315223)
win32 platforms. There is no publicly available algorithm, just a bunch of guesses that _might_ work on _some_
platforms. No solid way thanks to proprietary code :-/ Maurits' solution (https:/
seems to be the correct one.
2) Install win32 on-the-fly:
Maybe this is possible but it would require very complicated extra-actions. Unfortunately the error happens at a place
where we have no buildout environment available. Looks like a no-opt to me.
3) Provide win32 binaries with pywin32 included (distutils bdist_wininst).
Might work, but requires a lot more effort on releases. Furthermore there seem to be problems on some platforms with
distutils bdist_wininst. Not sure, whether resultung dists would work in virtual envs as well.
4) Just check on startup, whether we run on win32 and if so, whether win32 is installed. If not, abort with a sensitive
error message, telling the user how to install pywin32.
For now I tend to do 4).
--
Uli