installing Python 3 breaks bin\tahoe on Windows #1302

New issue

Closed

opened 2011-01-12 07:20:34 +00:00 by daira · 6 comments

daira commented

2011-01-12 07:20:34 +00:00

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.

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.

daira added the

labels 2011-01-12 07:20:34 +00:00

daira added this to the undecided milestone 2011-01-12 07:20:34 +00:00

daira commented

2011-01-12 08:11:54 +00:00

Author

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

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):

Have [scriptsetup]source:setuptools-0.6c16dev3.egg/setuptools/command/scriptsetup.py associate .pyscript\shell\open\command with the current Python interpreter (sys.executable when scriptsetup is run) rather than Python.File.
Make bin\tahoe.pyscript work with "any" Python version, but use the Python executable from build time to run support\Scripts\tahoe.pyscript.
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.

[to give more explicit paths, since there are two `tahoe.pyscript`s, one in `bin` and one in `support\Scripts`.]Edited 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](http://tahoe-lafs.org/trac/zetuptoolz/browser/trunk/launcher.c?rev=583#L186)) 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]source:setuptools-0.6c16dev3.egg/setuptools/command/scriptsetup.py 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.

daira commented

2011-01-12 08:35:08 +00:00

Author

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.

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.

daira commented

2011-01-13 02:56:06 +00:00

Author

In changeset:a8739c39ab59d64d:

bin/tahoe-script.template: improve the error message if we end up running under Python 3. refs #1302

In changeset:a8739c39ab59d64d: ``` bin/tahoe-script.template: improve the error message if we end up running under Python 3. refs #1302 ```

daira commented

2011-02-25 00:49:16 +00:00

Author

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 modified the milestone from undecided to soon

2011-02-25 00:49:16 +00:00

daira modified the milestone from soon to 1.10.0

2011-08-12 15:34:33 +00:00

daira modified the milestone from 1.11.0 to 1.12.0

2013-08-13 23:03:26 +00:00

daira commented

2016-01-15 18:04:59 +00:00

Author

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.)