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
.pth file in site-packages is skipped because it is hidden
- better diagnostics for this case in normal interpreter startup
- clearer documentation that hidden
.pth files 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
.pth file
- the generated
.pth file in site-packages has the UF_HIDDEN flag
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
.pth files 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
Bug report
Bug description:
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'
-rw-r--r-- 1 mima0000 staff hidden 49 Apr 4 19:32 _mcporter_bridge.pth
After removing the flag (
chflags nohidden <path>), the.pthfile is processed and the editable install works again.Why this is problematic
From a user perspective, the observable error is just:
That strongly suggests a broken venv, wrong interpreter, failed install, or incorrect
PYTHONPATH. It does not suggest that a.pthfile 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
.venvis also a very common virtual environment directory name.Expected behavior
At minimum, I would expect one of these:
.pthfile insite-packagesis skipped because it is hidden.pthfiles disable their path injection behaviorI am not necessarily arguing that hidden
.pthfiles 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
.pthfile 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:
.pthfile.pthfile insite-packageshas theUF_HIDDENflagThen Python startup ignores that
.pthfile and the editable install no longer works.Environment
.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
.pthhandling.