Skip to content

Tkinter not installed correctly on Windows 3.15.0b2 #150836

Closed

Description

@terryjreedy

Bug report

Bug description:

3.15.0b1 was fine. 3.15.0b2 will not start tk/tcl. Difference must be incomplete upgrade to tk 9.0.

If I run the REPL with either the Start icon or py in a console, import tkinter works but a subsequent t = tkinter.Text() fails with

Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    t = tkinter.Text()
  File "C:\Programs\Python315\Lib\tkinter\__init__.py", line 3857, in __init__
    Widget.__init__(self, master, 'text', cnf, kw)
    ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Programs\Python315\Lib\tkinter\__init__.py", line 2853, in __init__
    self._setup(master, cnf)
    ~~~~~~~~~~~^^^^^^^^^^^^^
  File "C:\Programs\Python315\Lib\tkinter\__init__.py", line 2818, in _setup
    master = _get_default_root()
  File "C:\Programs\Python315\Lib\tkinter\__init__.py", line 330, in _get_default_root
    root = Tk()
  File "C:\Programs\Python315\Lib\tkinter\__init__.py", line 2535, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)
              ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
_tkinter.TclError: Can't find a usable tk.tcl in the following directories:
    //zipfs:/app/tk_library //zipfs:/lib/tk/tk_library //zipfs:/lib/tk //zipfs:/lib/tcl/tcl_library/tk9.0 //zipfs:/lib/tcl/tk9.0 C:/Programs/lib/tk9.0 C:/Programs/lib/tk9.0 C:/lib/tk9.0 C:/Programs/library

This probably means that tk wasn't installed properly.

The IDLE icon in the start menu does not work. If I pin it to taskbar and click, the blue circle starts and quickly stops. The one for older versions start, quickly stop, and quickly restart until IDLE runs. In a console, py -m idlelib fails at the same _tkinter.create(...) call with the same message.

I have seen a similar message before and I believe the list of directories is obsolete. In a local build, I believe the tcl/tk file needs to be in PCbuild/. My 3.16 build works fine. Installations used to have DLLs/tcl86t.dll and tk86t.dll. 3.15.0b2 has tcl9tk90.dll and tcl90.dll (no t suffix). Is _tkinter.dll looking for those names?

CPython versions tested on:

3.15

Operating systems tested on:

Windows

Linked PRs

Activity

  1. terryjreedy commented on Jun 5, 2026

    @terryjreedy
    MemberAuthor

    @jjhelmus "I was able to get Tkinter working with an install of 3.15.0b2 on Windows by adjusting the files in the tcl directory."
    This works. It makes tcl/ look similar to what it did with 8.6. Thank you for the patch. Just curious, does it make tkinter run with compressed zip instead of expanded files?

    I installed from old-style download ...64.exe. I presume same failure with new installer.

    @nibedanmohanta9-arch A correct version-specific pip command would be py -3.15 -m pip install <package>. Tkinter is not an installable package. Please test before posting.

  2. zooba commented on Jun 8, 2026

    @zooba
    Member

    I'd also be interested to see how the fix looks that allows using the embedded ZIPs. For places where we are bundling 3rd party binaries, being more accepting of different builds of those binaries is better than merely fixing our own build - other people may be rebuilding from sources, and letting them have choices without having to patch our actual sources is better.

  3. hugovk commented on Jun 15, 2026

    @hugovk
    Member

    How is the PR looking for this release blocker? The next release is next week.

  4. zooba commented on Jun 15, 2026

    @zooba
    Member

    My last question still stands - if we can fix this in Tkinter rather than in our build commands for our own copy of Tcl, I think that would be better.

  5. added a commit that references this issue on Jun 16, 2026
  6. jjhelmus commented on Jun 16, 2026

    @jjhelmus
    Contributor

    This can be address in _tkinter by attempting to mount the Tk DLL as a a zipfs with a location that tcl_findLibrary searches (e.g. //zipfs:/lib/tk). If the DLL has an embedded tk_library then it will be found, if not the mount will be ignored and the existing behavior proceeds.

    #151562 implements this change.

  7. zooba commented on Jun 17, 2026

    @zooba
    Member

    Thanks @jjhelmus, I like how that looks, and it ought to be more future proof, if I understand correctly? Interested in others' thoughts as well.

    I'll leave a comment or two on that PR, since I think it's worth making it ready to merge, but my other big question is whether this should be used on all platforms? Is this a Windows-only feature from Tcl, or is there benefit to mounting it on all OSs?

  8. jjhelmus commented on Jun 18, 2026

    @jjhelmus
    Contributor

    my other big question is whether this should be used on all platforms? Is this a Windows-only feature from Tcl, or is there benefit to mounting it on all OSs?

    I suspect other platform would benefit from mounting the Tk DSO/DLL if it contained an embedded tk_library. Especially if the CPython install is relocated or determined at install time rather that build time. I need to do some testing to see if the current situation causes problems. Most distributions I know of either us a hardcoded path to the Tk library (e.g. Linux distro provided CPython) or disable embedding (python-build-standalone, MacPorts) which avoids the issue seen here.

  9. jjhelmus commented on Jun 18, 2026

    @jjhelmus
    Contributor

    I tested out linking Tcl/Tk with embedded library on both macOS and Linux in python-build-standalone and neither have issues with Tkinter, it seems like this issue is limited to Windows.

    Specifically Tcl uses the executable relative fallback in tcl_findLibrary to find the DSOs with the embedding in <prefix>/lib when the executable (python) is in <prefix>/bin.

  10. zooba commented on Jun 19, 2026

    @zooba
    Member

    Well, it sounds like @jjhelmus has the only opinion here (other than me), so let's go with doing the mount on Windows only and see what comes out of it.

  11. added a commit that references this issue on Jun 19, 2026
  12. added a commit that references this issue on Jun 19, 2026
  13. hugovk commented on Jun 22, 2026

    @hugovk
    Member

    Thanks all, I've removed the release-blocker label.

  14. zooba commented on Jun 22, 2026

    @zooba
    Member

    Closing this as completed, we can reopen if it is still busted.

  15. terryjreedy commented on Jun 22, 2026

    @terryjreedy
    MemberAuthor

    IDLE is working fine. There is still an open PR. Was it superceded? Should it be closed?

  16. zooba commented on Jun 22, 2026

    @zooba
    Member

    IDLE is working fine. There is still an open PR. Was it superceded? Should it be closed?

    Yes, and not yet (unless you're confident enough that this fix will work after install to go and close the other one).

  17. added a commit that references this issue on Jul 5, 2026
  18. added a commit that references this issue on Jul 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions