Re: [Gnumed-bugs] <bug>: still happening

On Tue, Aug 25, 2015 at 08:30:41PM +0200, slappinjohn wrote:

> rc3 acts like this:
> 
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>gm-from-vcs.bat
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # GNUmed tarball start up batch file
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # normally we would like to use a link but Python
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # on Windows seems to have problems importing
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # modules from directory links
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM mklink /J ..\Gnumed ..\client
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # hence we use xcopy: http://commandwindows.com/xcopy.htm
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # note that no (old) link should pre-exist lest we overwrite ourselves
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>xcopy ..\client ..\Gnumed /E /I /F /H /O /Y
> Zugriff verweigert
> 0 Datei(en) kopiert

This is strange. Windows cannot copy files around despite the
fact that it should own the directories and files due to it
just having extracted them from a tarball ...

> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>set PYTHONPATH=..;
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>Python gnumed.py --log-file=gm-from-vcs.log --conf-file=gm-from-vcs.conf --local-import --debug
> 
> Running from local source tree (C:\Users\marc\Downloads\gnumed-client.1.5.7rc3)

It now duly detects that we intend to run from a local tree.

> Adjusting PYTHONPATH ...
> 
> GNUmed startup: Cannot load GNUmed Python modules !
> ---------------------------------------------------
> CRITICAL ERROR: Program halted.
...
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client
> C:\Python27\lib\site-packages\setuptools-12.2-py2.7.egg
> C:\Python27\lib\site-packages\hl7-0.3.2-py2.7.egg
> C:\Python27\lib\site-packages\six-1.9.0-py2.7.egg
> C:\Python27\lib\site-packages\twain-1.0.5-py2.7-win32.egg
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client
> C:\WINDOWS\SYSTEM32\python27.zip
> C:\Python27\DLLs
> C:\Python27\lib
> C:\Python27\lib\plat-win
> C:\Python27\lib\lib-tk
> C:\Python27
> C:\Python27\lib\site-packages
> C:\Python27\lib\site-packages\PIL
> C:\Python27\lib\site-packages\win32
> C:\Python27\lib\site-packages\win32\lib
> C:\Python27\lib\site-packages\Pythonwin
> C:\Python27\lib\site-packages\wx-2.8-msw-unicode
>  
> If you are running from a copy of the CVS tree make sure you
> did run gnumed/check-prerequisites.sh with good results.
>  
> If you still encounter errors after checking the above
> requirements please ask on the mailing list.

Can you show us the log file ?  It probably all boils down to
Python 2.7 not being able to import from a symlinked directory.

> and after removing the Gnumed link - I thought it would be recreated -

It should, yes.

> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>gm-from-vcs.bat
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # GNUmed tarball start up batch file
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # normally we would like to use a link but Python
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # on Windows seems to have problems importing
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # modules from directory links
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM mklink /J ..\Gnumed ..\client
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # hence we use xcopy: http://commandwindows.com/xcopy.htm
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>REM # note that no (old) link should pre-exist lest we overwrite ourselves
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>xcopy ..\client ..\Gnumed /E /I /F /H /O /Y
> Zugriff verweigert
> 0 Datei(en) kopiert

So xcopy fails with the pre-existing link removed, too :-/

And Python duly tries to re-create the symlink:

> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>set PYTHONPATH=..;..;
> C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client>Python gnumed.py --log-file=gm-from-vcs.log --conf-file=gm-from-vcs.conf --local-import --debug
> 
> Running from local source tree
> (C:\Users\marc\Downloads\gnumed-client.1.5.7rc3)

> Creating local module import symlink ...
>  real dir: C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\client
>      link: C:\Users\marc\Downloads\gnumed-client.1.5.7rc3\Gnumed
> 
> Traceback (most recent call last):
>   File "gnumed.py", line 638, in <module>
>     setup_python_path()
>   File "gnumed.py", line 191, in setup_python_path
>     os.symlink(real_dir, link_name)
> AttributeError: 'module' object has no attribute 'symlink'

But Python on Windows doesn't _have_ os.symlink(). Even if it
had it wouldn't work (duh) because Windows requires a script
to be run with special priviledges in order to create
symlinks even if the user already _is_priviledged to do so |-/

	http://stackoverflow.com/questions/6260149/os-symlink-support-in-windows

I'd be interested in what happens if you manually copy

	../client to ../Gnumed

and run again.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346