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.

Sign up for GitHub

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

Jump to bottom

Restore fake-site module #1536

Closed
htgoebel opened this issue Sep 27, 2015 · 0 comments
Closed

Restore fake-site module #1536

htgoebel opened this issue Sep 27, 2015 · 0 comments
Assignees
@htgoebel
Labels
area:hooks Caused by or effecting some hook @high
Milestone
PyInstaller 3.0

Comments

@htgoebel
Copy link
Member

When running the current development head outside a virtual env, the original site-package is included. So we need to revert 12de5e2 and re-establish the fake-site module, see e47e4a2.

See also #1393 (comment) and #1507.
@htgoebel htgoebel added @high area:hooks Caused by or effecting some hook labels Sep 27, 2015
@htgoebel htgoebel self-assigned this Sep 27, 2015
@htgoebel htgoebel added this to the PyInstaller 3.0 milestone Sep 27, 2015
htgoebel added a commit to htgoebel/pyinstaller that referenced this issue Sep 27, 2015
@htgoebel
Restore fake-site module.
5dac9d8 
This reverts 12de5e2 and re-establish the fake-site
module, see e47e4a2.

David Vierra wrote:

I'm wondering why, exactly, this hook is trying to bring in the actual
site.py. In the past (e47e4a2), PyInstaller explicitly avoided
bundling the original site.py, inserting a fake site module instead.
It did this because importing the real site module may cause items to
be added to sys.path, fouling the module search process at runtime.
(See pyinstaller#510 for discussion). Later (12de5e2), after setting the
interpreter option to disable automatic import of site.py, PyInstaller
dropped the fake-site module entirely.

This meant that the real site.py would still be bundled, but it
wouldn't be imported except when some other module explicitly imports
it (...for whatever reason). Almost immediately afterward (8eb40c3),
the current hook-site.py was added, to bundle the site.py from the
base installation when running in a virtualenv.

When some other module does explicitly import site, this does the same
sys.path manipulation for site-specific folders (and .pth files)
that's normally done on interpreter startup when we don't tell it
otherwise (via -s or Py_NoSite=1).

I think including the real site.py is not correct for the reasons
given in pyinstaller#510 - PyInstaller built apps are self-contained so all the
concepts related to "site-specific" stuff don't apply. hook-site.py
should go back to inserting a fake site module that just does the bare
minimum of what is needed to support modules that import site
directly.


This closes pyinstaller#1536.
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@htgoebel htgoebel

Labels
area:hooks Caused by or effecting some hook @high
Projects
None yet
Milestone
PyInstaller 3.0
Development

No branches or pull requests
1 participant
@htgoebel