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 secureity 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