[python-win32] AMD64 build 220 for python 3.6 - installer looking for registry entry 3.6-32 which is probably incorrect for the x64 installer

[pywin32 at derketo.com]

Vielen dank Waldemar.

I echo your sentiments about Christoph's wonderful site - it has been a 
life saver for me on several occasions, and I had not thought to look 
there yet.

I have also poked around a bit between conf calls this morning and have 
just discovered that I had a pythonpath problem in terms of loading it 
at all, so I can now load it and the sqlsever module I am using seems 
happy with it - no weird crashes as yet from architectural 
incompatibilities.

It is slightly premature in terms of testing but at first blush I think 
that the problem may therefore be that the sourceforge x64 installer has 
x64 code in it but is just looking for the wrong registry entry. Lack of 
ability to put the path in yourself once it has failed to find it in the 
registry exacerbates the problem.

I ran it elevated and even though it reported success it did not put the 
toolkit onto my pythonnpath so there may also be another loose end 
there. I will try your suggestion about explicitly running the post 
install script, Waldemar, but it is also very possible this is normally 
an exercise for the reader anyway.

Thanks again.

regards
Rick

On 13/02/2017 15:19, Waldemar Osuch wrote:
> Not a solution per say but a workaround if you are interested is:
> 1) Download the pywin32 in the wheel format from  Christoph Gohlke's, 
> "thanks god it exists" site
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#pywin32 
> <http://www.lfd.uci.edu/%7Egohlke/pythonlibs/#pywin32>
>
> 2) Get the one appropriate for your Python version (
> pywin32‑220.1‑cp36‑cp36m‑win_amd64.whl)
>
> 3) use "pip install <libname>.whl to install it.
>
> 4) Run
>  `python.exe Scripts\pywin32_postinstall.py -install` from an elevated 
> command prompt.
> As the site mentions.  The key is "elevated command prompt".
>
> w/o