potiuk commented on code in PR #72567:
URL: https://github.com/apache/airflow/pull/72567#discussion_r4024510069
##########
dev/breeze/doc/03_developer_tasks.rst:
##########
@@ -399,6 +399,15 @@ in ``--from-ref`` and ``--to-ref`` flags.
If the cache gets broken, run ``breeze down --cleanup-mypy-cache`` which
wipes the docker
volume and every per-hook ``.build/mypy-venvs/`` and
``.build/mypy-caches/`` directory.
+.. note::
+
+ Python bytecode (``.pyc``) compiled from the mounted sources inside the
container is written
+ to the ``airflow-pycache-volume`` docker volume (``PYTHONPYCACHEPREFIX``)
rather than next to
+ the sources, so it never shows up in your checkout but survives between
``breeze shell`` and
+ ``breeze start-airflow`` runs. This noticeably speeds up every ``airflow``
command and component
+ start-up, especially on macOS where reading sources through the bind mount
is slow.
+ Run ``breeze down --cleanup-pycache`` to wipe the volume.
Review Comment:
Non-blocking doc nit. Two facts a reader (me, an hour ago) will otherwise
re-derive are missing here: that one volume is safe across Python versions, and
that it is *not* isolated per worktree.
```suggestion
The cache is safe to share across Python versions: ``.pyc`` file names
keep the
interpreter tag (``foo.cpython-310.pyc`` vs ``foo.cpython-312.pyc``), so
bytecode is
never reused across versions. It is shared across worktrees, though --
sources always
mount at ``/opt/airflow`` and freshness is checked by source mtime and
size, so
alternating between worktrees keeps invalidating the other one's entries.
Run ``breeze down --cleanup-pycache`` to wipe the volume.
```
The worktree point is not a defect -- it is correct, just not free. Because
breeze always mounts sources at `/opt/airflow`, two worktrees map onto the same
cache paths, and since invalidation is source mtime + size, alternating between
them keeps invalidating each other's entries. Same family as the
same-second-edit limit you already documented.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
