Can't import tkinter in Python 3.5.0rc1

[mrabarnett]

BPO	24847
Nosy	@pfmoore, @larryhastings, @rbtcollins, @tjguk, @bitdancer, @zware, @zooba
Files	remove_vc140_ext.patch remove_vc140_py.patch tcltk_ucrt_option.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/zooba'
closed_at = <Date 2015-08-25.01:56:33.779>
created_at = <Date 2015-08-12.01:14:33.559>
labels = ['expert-IDLE', 'type-bug', 'release-blocker']
title = "Can't import tkinter in Python 3.5.0rc1"
updated_at = <Date 2015-08-25.21:35:25.530>
user = 'https://bugs.python.org/mrabarnett'

bugs.python.org fields:

activity = <Date 2015-08-25.21:35:25.530>
actor = 'python-dev'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2015-08-25.01:56:33.779>
closer = 'larry'
components = ['IDLE']
creation = <Date 2015-08-12.01:14:33.559>
creator = 'mrabarnett'
dependencies = []
files = ['40168', '40169', '40206']
hgrepos = []
issue_num = 24847
keywords = ['patch']
message_count = 28.0
messages = ['248437', '248439', '248440', '248443', '248444', '248445', '248446', '248447', '248448', '248471', '248522', '248525', '248613', '248614', '248623', '248655', '248659', '248665', '248668', '248755', '248759', '248787', '248802', '248815', '248845', '248890', '249080', '249163']
nosy_count = 10.0
nosy_names = ['paul.moore', 'larry', 'rbcollins', 'tim.golden', 'mrabarnett', 'r.david.murray', 'BreamoreBoy', 'python-dev', 'zach.ware', 'steve.dower']
pr_nums = []
priority = 'release blocker'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24847'
versions = ['Python 3.5', 'Python 3.6']

[mrabarnett]

I'm unable to import tkinter in Python 3.5.0rc1.

The console says:

C:\Python35>python
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Python35\lib\tkinter\__init__.py", line 35, in <module>
     import _tkinter # If this fails your Python may not be configured for Tk
ImportError: DLL load failed: The specified module could not be found.

I'm on Windows 10 Home (64-bit).

[zooba]

Yep, this is my fix for the same issue pre-RC1 not quite working out (I'm guessing some difference between my dev box and my build box).

If you go into your DLLs directory there's an extra subdirectory (Microsoft.VC140.CRT or similar) with a single DLL in it. Move that DLL up one level to the DLLs folder and you should be fine.

I'll work up a setup authoring fix immediately, but really I want to patch Tcl/tk to not rely on that DLL so that we can be truly independent of CRT versioning.

[mrabarnett]

Yes, I can confirm that that works for me.

[python-dev]

New changeset 3cb97ffd9ddf by Steve Dower in branch '3.5':
Issue bpo-24847: Fixes tcltk installer layout of VC runtime DLL
https://hg.python.org/cpython/rev/3cb97ffd9ddf

New changeset 13ceedb92923 by Steve Dower in branch 'default':
Issue bpo-24847: Fixes tcltk installer layout of VC runtime DLL
https://hg.python.org/cpython/rev/13ceedb92923

[zooba]

Pull request for 3.5.0 is at https://bitbucket.org/larry/cpython350/pull-requests/3/issue-24847-fixes-tcltk-installer-layout/diff. When merged, this can change back to normal priority for the rest of the fix.

Long term (probably 3.5.1, possibly 3.5.0rc2 if I can get it done) I want to build tcl/tk differently so we don't have the dependency on this unstable part of the VC runtime, but deploying it now is the easiest way to keep tcl/tk working.

The biggest risk is that extension authors may plan to depend on it - currently distutils bdist_ext does not use it, but that is already causing compatibility issues with old code (a.k.a. code that needs updating for a newer compiler), so there'll be a bit of wait and see.

Maybe we'll just have to accumulate all versions of vcruntime*.dll from now until forever (and backport them), but I hope we can avoid that.

[larryhastings]

I trust you, Steve, but I still want to see it get a review before I pull it. Can you find someone qualified to review the change?

[zooba]

Zach has the best chance of being able to review, if only because he can probably build the installer. I've added all the Windows experts just in case. There's quite a bit of MSBuild magic involved here though - I have trouble getting good reviews of this kind of change at work :(

For whoever is looking - the InstallFiles items are processed by getting all the Included files, stripping SourceBase off the start and replacing it with Source (so a nop in this case) and including that file in the installer. The file is installed into Target (which is actually a directory reference into the installer, but DLLs is as self-explanatory as it seems) plus the relative path from TargetBase to the original filename. In this case, the old TargetBase was too short and so the file was installed with the last directory segment; after the fix the last directory segment is excluded. (Yes, the Source and SourceBase changes aren't really necessary, but changing them to match will avoid unnecessary questions in the future.)

I should really add more documentation about this... Tools/msi/readme.txt has a bit, but not at this level.

[BreamoreBoy]

Works fine for me, also on Windows 10 Home 64 bit.

c:\Python35>python.exe
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> tkinter.__file__
'c:\\Python35\\lib\\tkinter\\__init__.py'

[zooba]

Mark, IIRC you've got VS 2015? Anyone with VS 2015 installed (or the full CRT redistributable) is unaffected because the required file is already in their system path - this includes my build machine, which is why all my tkinter tests passed before pushing the release (currently figuring out a way to avoid this in future without needing extra machines).

This is also why I'm worried about extensions built with non-distutils based tools. Anyone with the compiler has the current version of vcruntime.dll, but users may not (this is the versioning issue - someone might build with vcruntime150.dll which then won't work with vcruntime140.dll, so I'm trying to just block the DLL entirely).

[zooba]

Attaching two patches that fix the tcl/tk build to not require vcruntime140.dll at all. This is the better fix, though I haven't yet tested it thoroughly enough to convince myself that it's ready. One patch is for tcl/tk/tix themselves (which I'll submit upstream if accepted) and the other is for our side of the build process. (There'll also be a change to our installer if these go in.)

Presented here for openness, reviews and feedback. Still want to get testing on the existing 3.5.0 change to convince Larry that it's good to go.

[bitdancer]

Is this buildbot failure:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/189

related to this issue?

LINK : fatal error LNK1104: cannot open file 'C:\buildbot.python.org\3.5.kloth-win64\build\PCBuild\amd64\_tkinter_d.pyd' [C:\buildbot.python.org\3.5.kloth-win64\build\PCbuild\_tkinter.vcxproj]