installing Python 3 breaks bin\tahoe on Windows

[davidsarah]

Installing native-Windows Python 3 breaks bin\tahoe, because it changes the registry association for 'Python.File' to the Python 3 interpreter. This results in syntax errors because tahoe.pyscript is not compatible with Python 3.

(The exact version/installer I used was "Windows x86 MSI Installer (3.2b2)" from ​http://www.python.org/download/releases/3.2/ .)

This is strictly speaking a bug in zetuptoolz, but only Tahoe uses zetuptoolz.

Workarounds:

• bin/tahoe from a Cygwin prompt still works, because that uses the shebang line which is correct.
• c:\python26\python bin\tahoe (or whatever the full path to Python 2.x is) works.
• python bin\tahoe works if Python 2.x is on the PATH. The Python 3 installer does not change the PATH (either for the current user or the system-wide one).

Although building Tahoe-LAFS causes .pyscript to be associated with Python.File, it does not change the association for Python.File (intentionally, because that would be impolite!), so rerunning a build, install, or python setup.py scriptsetup does not fix the problem.

[davidsarah]

[Edited to give more explicit paths, since there are two tahoe.pyscripts, one in bin and one in support\Scripts.]

This is a regression in Tahoe-LAFS v1.8.0 relative to v1.7.1, caused by the fix to #1074. Before v1.8.0, bin\tahoe.exe (built from ​this source) would have run the Python executable from support\Scripts\tahoe-script.py's shebang line, which is the one used for the Tahoe build/install, so it would have worked for the same reason as it does from a Cygwin prompt.

So, my bad :-(

Possible solutions (that don't regress #1074):

1. Have scriptsetup associate .pyscript\shell\open\command with the current Python interpreter (sys.executable when scriptsetup is run) rather than Python.File.
2. Make bin\tahoe.pyscript work with "any" Python version, but use the Python executable from build time to run support\Scripts\tahoe.pyscript.
3. Make bin\tahoe something other than a Python script (for example, a .bat or .cmd file).

Note that a. has the property that if you run build/install with version X of Python, then all copies of Tahoe for the current user (since v1.8.0) will then use version X, rather than just the one you're building/installing. That differs from the behaviour on other operating systems or from a Cygwin prompt.

I think b. is a bad idea; we eventually want to get rid of bin\tahoe.pyscript (at least Brian and I do). Also, it imports pkg_resources, so pkg_resources would also have to work in Python 3, which is impractical/too much work.

I tested c. with a bin\tahoe.cmd file containing

@C:\Python26\python.exe <full path to renamed tahoe.pyscript> %*

It worked once, and from then on failed silently. (I've seen this behaviour before with .cmd and .bat files on my system, and have never got to the bottom of it. Perhaps the Windows installation is just broken.)

In summary, I'm not sure how to fix this yet.

[davidsarah]

It could also be argued that, since Python 3 is not compatible with Python 2, it is a bug in the Python 3 installer that it modifies the Python.File entry, rather than adding a Python3.File entry. The latter would have avoided the problem (no matter what the association is for .py).

​http://bugs.python.org/issue4485 is somewhat relevant; I'll comment on that ticket or find/file a more specific one. However, we need a workaround anyway.

[david-sarah@…]

In a8739c39ab59d64d:

(The changeset message doesn't reference this ticket)

[davidsarah]

See also #1371, which is caused by incorrect permissions on the Python.File key. Solutions a. or c. above would fix that problem as well. I intend to implement a.

[daira]

When we remove zetuptoolz and switch to newer setuptools, this will be fixed because the scriptsetup code will go away. (Newer setuptools generates a Windows executable, and if this causes any regressions then we'll try to fix them upstream.)

[warner]

Milestone renamed