Comment 1 by jteh on 2014-01-22 04:26
Hmm. I hadn't considered this. Thanks for reporting.

I went with the .py extension because that's how Python installs by default. Unfortunately, the Python installer doesn't provide an option to add Python to the search path.

I'd rather not require people to manually change their search path. While it's not that difficult, it does require an understanding of how the variable works and the option isn't always easy to find.

It seems we can use the reg tool to query the registry and the for command to capture its output. I don't know how to use reg yet, but we'll want something like this:

for /f "usebackq delims=" %%p in (`reg query xxx`) do %x\python.exe ...

Sidenote: the Windows command interpreter is just so ugly!

Comment 2 by driemer.riemer@... on 2014-01-22 06:12
please note however, that people who have python 2 and 3 installed will have the .py extention registered to only one of them.

Comment 3 by camlorn on 2014-01-22 16:55
That's not a bad setting to make people change anyway. In order to start NVDA, you still have to do pythonw, which implies pythonw being on the path. And the python 2 versus python 3 is a good point as well. For casually building NVDA for some reason, it's overkill. For actually developing on NVDA, you've got to change it-especially if there's multiple pythons on your system (sidenote: god help you if you end up with that and don't know what you're doing).
I'll look into this if no one beats me to it. I can probably figure out the command prompt stuff now that you've pointed me at the right command. Yes, it is ugly. It used to be why i kept cygwin around; nowadays, I'd just use python if I needed a serious script. ETA on me having time for this is Saturday-isn't college fun?

Comment 4 by jteh (in reply to comment 3) on 2014-01-22 22:39
Replying to camlorn:

In order to start NVDA, you still have to do pythonw, which implies pythonw being on the path.

Not if you keep .pyw associated with pythonw, which is the default, but then we get back to people changing the defaults or having two versions of Python. :)

This is one reason I actually prefer keeping the barrier of entry to running NVDA from source a bit higher. People complain about not being able to easily build/run from the source, but when we try to make it easier, we run into problems like this. Also, when you make it easier, some don't expect to need as much technical knowledge and so can't figure things out when they run into trouble.

To be honest, I'm tempted to wontfix this, since you're using a non-default configuration. That way, we just say we only support the default config and anyone with enough knowledge to change that config also has enough knowledge to figure out how to fix it. Same goes for nvda.pyw.

Comment 5 by jteh on 2014-01-22 22:41
FWIW, we'll still take a patch to fix this, but even if you do, as you pointed out, some may run into trouble with nvda.pyw.

Comment 6 by camlorn on 2014-01-22 23:56
It looks like the registry option is going to be interesting, in that it depends on a lot of stuff. The keys are not officially documented and depend on architecture and operating system version. I don't know that we'll be able to get something that hits all the places without making it, itself, a python script; and at that point you might as well do nothing. I opened this because I assumed that my setup was common. I still believe that it is. That said, I don't know if a reasonable patch that will fix it for everyone is possible. I did not intend this to be a "let's lower the bar more" ticket, merely a this assumption about how I use python in the build system is invalid, and probably is for others, too.
I'm not liking the fact that you override my scons, and will say that fixing the problem requires that one figure out why in the world one is getting a text editor from something that should be a batch script over in site-packages. That said, wontfix may be the best option; the solution all raise the entry barrier, if only slightly. If we're looking for something truly better, there is one potential option: rename scons.py to something that is not scons.py, and instruct the user to "run notscons.py from the root of the source tree." I don't know that it is worth it.
I am going to leave the wontfix decision to you. I opened this without a definite valid alternative in mind; if no such alternative exists, then obviously we can't.
As for generally lowering the barrier: the barrier used to be way, way too high. Let's spend an entire day figuring that out, instead of patching high. The new system is a major improvement. I don't particularly see a problem with having it this low, but it definitely needs to be and stay lower than it was.

Comment 7 by mdcurran on 2014-01-23 00:42
I haven't read anything official, but are you saying that its not just:
hklm\software\Python\pythonCore\2.7\installPath@
(on 64-bit add \Wow6432Node after software if accessing with a 64-bit process).
Is that different on different Operating Systems?

Comment 8 by jteh on 2014-01-23 00:43
On Windows 8.1, this works (and I can't see why it wouldn't work on other operating systems):

for /f "usebackq skip=2 tokens=3*" %a in (`reg query HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath /reg:32 /ve`) do echo %a

Comment 9 by driemer.riemer@... on 2014-01-23 03:07
That should work. I was changing the name of python.exe to python2.exe, but after doing a bit of research, that is probably going to break a lot. The registry key exists on my windows 7 machine indeed.

Comment 10 by camlorn on 2014-01-23 22:02
I found a few different sources, and didn't have the foresight to bookmark. They all said slightly different things about where it goes. This might be a try and see sort of thing-the problem is that I can't find anything official, nor does everyone seem to agree. The sources I found are old, so it is quite possibly unified now and may work fine for everyone.

Comment 11 by jteh on 2014-01-23 22:53
I got this to work nicely on Windows 8.1, but it seems that:

1. In Windows XP 32 bit, the /reg:32 switch is invalid because there was no concept of 64 bit for that version of Windows. That's easy enough to fix with an if condition and a variable.
2. The output of reg.exe seems to have changed slightly. In XP, I have to skip 4 lines, but in 8.1, only 2. This is harder to make conditional and I'm also not sure in which OS the output changed.
   For reference, here's the command for Windows 8.1 (and ossibly earlier):

for /f "usebackq skip=2 tokens=3*" %%p in (`reg query HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\InstallPath /ve`) do %%ppython.exe -c "import sys; sys.path.insert(1, r'%~dp0\miscDeps\python'); import SCons.Script; SCons.Script.main()" %*

I'm not really willing to spend much more time on this myself. We'll happily accept a patch, but it has to work on Windows XP through Windows 8.1, both 32 and 64 bit.

Will the transition of NVDA from Python 2.x to 3.x affect this ticket in any way?

As far as I understand, the change would affect Windows XP only. Right?
@camlorn, @michaelDCurran, @josephsl.

cc: @derekriemer

No, this isn't xp specific.

I"m temped to close this. As we are in the process of moving to Python 3, it is safe to assume that a developer has the python launcher installed, so this issue is much less prevalent.