installing Python 3 breaks bin\tahoe on Windows #1302

New Issue

tahoe-lafs · 2011-01-12T07:20:34Z

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

tahoe-lafs added the

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

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

davidsarah commented

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

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

davidsarah commented

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

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.

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@jacaranda.org commented

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

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 ```

davidsarah commented

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

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.

tahoe-lafs modified the milestone from undecided to soon

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

tahoe-lafs modified the milestone from soon to 1.10.0

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

tahoe-lafs 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

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

tahoe-lafs added the

wontfix

label 2016-01-15 18:05:17 +00:00

daira closed this issue

2016-01-15 18:05:17 +00:00

tahoe-lafs modified the milestone from 1.12.0 to 1.11.0

2016-01-15 19:10:28 +00:00

warner commented

2016-03-22 05:02:52 +00:00

Milestone renamed

warner modified the milestone from 1.11.0 to 1.12.0

2016-03-22 05:02:52 +00:00