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

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.

Yes, I can confirm that that works for me.

New changeset 3cb97ffd9ddf by Steve Dower in branch '3.5':
Issue #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 #24847: Fixes tcltk installer layout of VC runtime DLL
https://hg.python.org/cpython/rev/13ceedb92923

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.

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?

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.

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'

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

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.

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]

No, any machine with Visual Studio installed is unaffected by this. That buildbot seems to have a previous failed/aborted build that still has some files locked. A reboot is the easiest solution, but going through and killing any extra processes is what's needed there.

I'll try to get a proper review done before Wednesday.  From a cursory glance, this looks fine, but unpalatable.  The solution I'd really like would be to create proper .vcxprojs for Tcl/Tk/Tix (partly because that would also fix an issue with building with ICC), but that's a *lot* of extra work.

To expand on 'unpalatable': I'd rather we not have to carry any patches against the Tcl/Tk sources (Tix I care less about, since we seem to be the de facto maintainers of it).

I'll submit them upstream if we decide they're what we want, as I've done with other patches for them. Or if we want to figure out reliable builds with avcxproj I'm okay with that too.

The fix that needs testing now is already checked in for 3.5.1. We just need confirmation that it works to merge it into 3.5.0.

I've made a build of rc1 with the installer fix that's currently being considered for 3.5.0:

https://pythonbuilds.blob.core.windows.net/temp/python-24847-1.exe

(This is a test-marked build that *should not* affect another 3.5 install, but if it does please tell me so I can fix it. After removing it, a Repair on 3.5.0rc1 should fix any issues.)

Currently working on a test build of the fix based on the attached patches, which is the correct fix for this issue.

A second test build with the attached patches applied directly to 3.5.0rc1. (You'll need to remove the first test build before installing this).

https://pythonbuilds.blob.core.windows.net/temp/python-24847-2.exe

Any confirmation that these work would be appreciated. I don't think we should rewrite the tcl/tk build for 3.5.0 completely at this stage, so this one is my preferred fix for 3.5.0.

On running the installer, Windows reports:

"""Windows SmartScreen prevented an unrecognised application from starting. Running this application might put your PC at risk.

Application: Python-24847-2.exe
Publisher: Unknown Publisher"""


When installed, Tkinter appears to work without a problem.

This is on Windows 10 Home (64-bit) without VS 2015.

Yeah, should have mentioned the smartscreen warning. The official builds are Authenticode signed, which prevents that warning appearing.

I promise the installers are safe :)

Looks good to me. I think you should commit (or perhaps you are pending PR approval on the rc branch or something?)

I'll withdraw my current pull request and make a new one tomorrow. I prefer to check into 3.5.1 immediately, and especially since this one will be covered by the buildbots, so I'll do that first.

Posting the actual changes made to Tcl and Tk, mainly so I can link them from the upstream issue I'm filing.

New changeset 19ac02a522ba by Steve Dower in branch '3.5':
Issue #24847: Removes vcruntime140.dll dependency from Tcl/Tk.
https://hg.python.org/cpython/rev/19ac02a522ba

New changeset 0e2620831f17 by Steve Dower in branch '3.5':
Issue #24847: Fixes Tix revision number and reverts fix for the wrong revision.
https://hg.python.org/cpython/rev/0e2620831f17

New changeset 9cc3f2f2d810 by Steve Dower in branch 'default':
Issue #24847: Fixes Tix revision number and reverts fix for the wrong revision.
https://hg.python.org/cpython/rev/9cc3f2f2d810

Larry - PR for you at https://bitbucket.org/larry/cpython350/pull-requests/6/issue-24847-removes-vcruntime140dll/diff

The buildbots are happy with this change, and so am I. Zach also had a look at the Tcl and Tk patches, and I've already heard back from upstream that they like the change but need it expanded before they'll take it (that won't affect what we need for our builds though).

FYI - the Tcl and Tk changes have been committed upstream: http://core.tcl.tk/tcl/tktview/00189c4afcb9e2586301d711f71383e48817a72d

Pull request accepted and merged.

New changeset dc9bdddca59b by Steve Dower in branch '3.5':
Issue #24847: Removes vcruntime140.dll dependency from Tcl/Tk.
https://hg.python.org/cpython/rev/dc9bdddca59b

New changeset b77ceefc34ff by Larry Hastings in branch '3.5':
Merged in stevedower/cpython350 (pull request #6)
https://hg.python.org/cpython/rev/b77ceefc34ff