# Entry-Point Runtime — Python

## Signals to gather
- `argv0` equals `python`, `python3`, `pypy`, or an interpreter symlink.
- WSGI/ASGI servers: `gunicorn`, `uvicorn`, `hypercorn`, `daphne`.
- Task runners: `celery -A app worker`, `rq worker`, `pytest`.
- Presence of `requirements.txt`, `pyproject.toml`, `setup.cfg`, or `Pipfile`.
- `PYTHONPATH`, `PYTHONUNBUFFERED`, `DJANGO_SETTINGS_MODULE`, `FLASK_APP`, or application-specific env vars.
- Virtualenv detection (`/venv/bin/python`, `pyvenv.cfg`).

## Implementation notes
- When invoked as `python -m module`, resolve the module to a path if possible.
- For WSGI/ASGI servers, inspect command arguments (`app:app`, `module:create_app`) and config files.
- Recognise wrapper scripts such as `docker-entrypoint.py` that eventually `exec "$@"`.
- Support zipped apps or single-file bundles by checking `zipapp` signatures.

## Evidence & scoring
- Increase confidence when module or script exists and dependencies are present.
- Capture evidence for env variables, config files, or known server arguments.
- Penalise ambiguous invocations (e.g., `python -c "..."` without persistent service).

## Edge cases
- Supervisors launching multiple Python workers fall back to `Supervisor` classification with Python listed as child.
- Conda environments use different directory structures; look for `conda-meta` directories.
- Alpine distroless images may ship `python` symlinks without standard libs—ensure script presence before final classification.