`pip install -e .` is in place, yet an email-digest service still imports an old clock-skew fix — how do you find which copy Python is loading?

### The failure looks like magic and is not An eleven-person team ships an email-digest service. Someone fixes a clock-skew bug in the scheduling module — timestamps a few seconds ahead of the sender's clock were rounding a digest into the previous window — and the fix works when they run the module directly, but the test suite and one colleague's checkout keep producing the old behaviour, even though everyone ran `pip install -e .`. Nothing here is mysterious: some other file is being imported, and Python will tell you which one. ### Step one: ask the import system, in the failing process The only authoritative answer comes from the process that actually misbehaves, so put the probe there — at the top of the failing test, or in the entry point: ```python import sys, importlib.util print(sys.executable) print(importlib.util.find_spec("digestlib").origin) ``` `find_spec` runs the real resolution without importing, and `origin` is the file that would be loaded. After an import, `digestlib.__file__` says the same thing for the module already in memory — and comparing the two is itself informative, because they differ when the module was imported before something mutated `sys.path`. ### Step two: name the shadow Four causes cover nearly every occurrence. **A leftover regular install.** The distribution was once installed normally — from an index, from a wheel, by a bootstrap script — and those real `.py` files still sit in `site-packages`. An editable install adds a redirection but does not delete the older copy's files if that copy was recorded by a different install path, and directories in `site-packages` are found by the ordinary path-based finder. Uninstalling the distribution repeatedly until pip reports nothing to remove, then reinstalling with `-e`, is the cure. **The wrong environment.** The interpreter running the tests is not the one that received the editable install. `sys.executable` and `sys.prefix` settle it in one line. **A directory earlier on `sys.path`.** `sys.path[0]` is the script's directory for `python script.py`, the current directory for `python -c` and the REPL, and the current directory for `python -m`. If a stale copy of the package — a `build/` tree, a vendored snapshot, an old checkout — lives there, it wins over anything the editable redirection contributes. `PYTHONPATH` entries also precede `site-packages`. Printing `sys.path` in order, and reading it top-down, is the whole diagnosis. Since 3.11, `PYTHONSAFEPATH` removes that leading directory entry, which makes an excellent experiment: if the failure disappears with it set, the shadow was local. **Nothing stale at all — just a cached module.** A module imported before your edit stays in `sys.modules` for the life of the process. Long-lived workers, notebook kernels and watch-mode runners all reproduce this. Restart the process. ### Step three: confirm what the install owns `importlib.metadata.files("your-dist-name")` lists the files the installed distribution claims, and `importlib.metadata.version()` confirms which distribution answered. If the listing contains the package's own `.py` files, this is a regular install pretending to be your source; if it contains only metadata and a `.pth`, the editable redirection is intact and the shadow is coming from `sys.path` instead. ### Why a src layout makes this rarer With the importable package under `src/`, the current directory contains nothing importable. `import digestlib` cannot silently resolve to the working tree by accident; it resolves only through the install, exactly as it will for a user. The failure mode inverts from "quietly imported the wrong copy" to "ImportError until you install", which is far cheaper to diagnose. In a flat layout, the project root doubles as an implicit path entry for anything launched from it, and that is what lets an uninstalled or shadowed package appear to work — and what lets a stale copy elsewhere take over when it does not. ### The habit worth demonstrating An interviewer is listening for whether you reach for evidence or for ritual. Reinstalling, clearing caches and deleting `__pycache__` are ritual. Printing `sys.executable`, the resolved origin and `sys.path` — in the failing process, in that order — is evidence, and it takes about fifteen seconds. Add it to the team's test bootstrap once and the whole class of report disappears, because the wrong path is visible in the failure output rather than in someone's guess.