Sibling module import fails in production despite working locally

When a Python script is executed directly with python path/to/script.py, CPython automatically places the script’s directory at the front of sys.path, allowing imports of sibling modules without installation. In production, the same code is often launched via a process manager, as a module (python -m package.module) or from a different working directory, which removes that implicit entry and can change the effective PYTHONPATH or user‑site settings. Additionally, file‑system case sensitivity differs between developer workstations and Linux servers, turning a case‑insensitive match into a ModuleNotFoundError. The reliance on the implicit current‑directory import is an unresolved design decision that makes code fragile when the entry point is not the package root and no warning is emitted.

What strategies ensure that sibling‑module imports remain reliable across development and production executions? Should projects avoid depending on the script‑directory entry in sys.path and instead use explicit package structures or adjustable paths? How can automated checks detect reliance on implicit current‑directory imports before deployment?