-
-
Notifications
You must be signed in to change notification settings - Fork 34.4k
Hidden .pth files inside .venv can silently break editable installs on macOS #148121
Description
Bug report
Bug description:
### Bug report
On macOS, editable installs can fail silently when the generated `.pth` file in `site-packages` has the `UF_HIDDEN` flag.
In this situation, `site.py` skips the `.pth` file, so the editable install is effectively ignored and imports fail with `ModuleNotFoundError`. The failure mode is very hard to diagnose because the default symptom looks like a normal environment or packaging mistake.
### What I observed
I observed the following behavior on macOS:
1. `pip install -e .` creates a `__editable__*.pth` file in the virtual environment's `site-packages`
2. that `.pth` file has the `UF_HIDDEN` file flag
3. `site.py` skips it because it is hidden
4. the editable install becomes ineffective
5. importing the package fails with `ModuleNotFoundError`
The key problem is not only that hidden `.pth` files are skipped, but that this can completely disable an editable install with no obvious warning in normal usage.
### Evidence
`python -v` shows that the `.pth` file is skipped:
import '_sitebuiltins' # <class '_frozen_importlib.FrozenImporter'>
Processing global site-packages
Adding directory: '/Users/mima0000/Desktop/repos/mcporter-bridge/.venv/lib/python3.12/site-packages'
Skipping hidden .pth file: '/Users/mima0000/Desktop/repos/mcporter-bridge/.venv/lib/python3.12/site-packages/_mcporter_bridge.pth'
`ls -lO` confirms the file has the hidden flag:
-rw-r--r-- 1 mima0000 staff hidden 49 Apr 4 19:32 _mcporter_bridge.pth
Python confirms the flag:
```python
>>> import os, stat
>>> p = "/Users/mima0000/Desktop/repos/mcporter-bridge/.venv/lib/python3.12/site-packages/_mcporter_bridge.pth"
>>> st = os.lstat(p)
>>> st.st_flags & stat.UF_HIDDEN
32768
After removing the flag (chflags nohidden <path>), the .pth file is processed and the editable install works again.
Why this is problematic
From a user perspective, the observable error is just:
ModuleNotFoundError: No module named mcporter_bridge
That strongly suggests a broken venv, wrong interpreter, failed install, or incorrect PYTHONPATH. It does not suggest that a .pth file was silently ignored because it had a file flag set.
This makes the issue extremely difficult to diagnose, especially since editable installs are a standard development workflow and .venv is also a very common virtual environment directory name.
Expected behavior
At minimum, I would expect one of these:
- a visible warning when a
.pthfile insite-packagesis skipped because it is hidden - better diagnostics for this case in normal interpreter startup
- clearer documentation that hidden
.pthfiles disable their path injection behavior
I am not necessarily arguing that hidden .pth files should always be processed. I understand there may be security reasons for the current behavior. But the current failure mode is too silent and too misleading for a common development workflow.
Actual behavior
The .pth file is skipped, the editable install does not take effect, and the user only sees later import failures.
Reproduction
I can provide an exact repro if needed, but the essential condition is:
- macOS
- a virtual environment
- an editable install that relies on a
.pthfile - the generated
.pthfile insite-packageshas theUF_HIDDENflag
Then Python startup ignores that .pth file and the editable install no longer works.
Environment
- macOS: 15.x (observed; likely affects earlier versions as well)
- Python: 3.12.7 | packaged by Anaconda, Inc.
- Python distribution: Anaconda3
- pip: 24.2
- build backend: hatchling 1.29.0 (generates
.pthfiles for editable installs)
Suggested direction
Even if the hidden-file check is intentional, I think this case deserves at least a visible warning or improved diagnostics, because it breaks editable installs in a way that is very difficult for users to connect back to .pth handling.
### CPython versions tested on:
CPython main branch
### Operating systems tested on:
macOS