Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hooks: tkinter: avoid collecting data from system Tcl/Tk framework on macOS #5217

Merged
merged 2 commits into from Oct 10, 2020

Conversation

rokm
Copy link
Member

@rokm rokm commented Oct 2, 2020

After a discussion with @bwoodsend, we reached conclusion that in the case of system Tcl/Tk framework on macOS, it makes no sense to collect data when we do not collect the shared library (which we do not; and is not needed anymore as #5172 ensures that the system libraries are used correctly). So this PR removes the collection of data from macOS' system Tcl/Tk. This affects only python builds that use system Tcl/Tk - older python.org builds (e.g., 32/64-bit 3.6.5) and apparently homebrew python.

As a bonus, this also takes care of the error in tkinter hook with homebrew python on macOS 11, which was reported in #5040.


On macOS, we do not collect system libraries in general; if tkinter uses system Tcl/Tk 8.5 framework (older 32/64-bit
python.org builds, or brew python), we do not collect its Tk and Tcl shared library, either. Therefore, it makes little sense to
collect the data (scripts and modules) from the system framework, either.

This commit modifies the behavior of both _tkinter stdhook and rthook on macOS. The stdhook now treats (None, None) returned by _find_tcl_tk() as an indicator that the system framework is used and that data directories should not be collected. The rthook now sets TCL_LIBRARY and TK_LIBRARY environment variables if collected tcl and tk directories exist, but does not raise error anymore if they do not (under assumption that they have not been collected from the system framework).

The behavior under other OSes remains unchanged.

Copy link
Member

@bwoodsend bwoodsend left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like my review isn't worth much here seeing as I can't test it.

@Legorooj
Copy link
Member

Legorooj commented Oct 4, 2020

I'm going to wait until #5175 is merged to review this. Is that PR ready to merge @rokm or is there still work to be done?

@rokm
Copy link
Member Author

rokm commented Oct 4, 2020

I'm going to wait until #5175 is merged to review this. Is that PR ready to merge @rokm or is there still work to be done?

It should be ready to merge - as far as I'm concerned, we should be collecting all those Tcl modules to ensure that packaged environment is the same as the source one.

… macOS

On macOS, we do not collect system libraries in general; if
tkinter uses system Tcl/Tk 8.5 framework (older 32/64-bit
python.org builds, or brew python), we do not collect its Tk and
Tcl shared library, either. Therefore, it makes little sense to
collect the data (scripts and modules) from the system framework,
either.

This commit modifies the behavior of both _tkinter stdhook
and rthook on macOS. The stdhook now treats (None, None) returned
by _find_tcl_tk() as an indicator that the system framework is
used and that data directories should not be collected. The rthook
now sets TCL_LIBRARY and TK_LIBRARY environment variables if collected
tcl and tk directories exist, but does not raise error anymore
if they do not (under assumption that they have not been collected
from the system framework).

The behavior under other OSes remains unchanged.
@rokm rokm marked this pull request as ready for review October 5, 2020 12:23
Copy link
Member

@Legorooj Legorooj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this @rokm

@Legorooj Legorooj merged commit ea09e7d into pyinstaller:develop Oct 10, 2020
@rokm rokm deleted the hooks-tkinter-nosysdata branch October 14, 2020 17:34
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants