You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up from #4927 / #4933, where a star-import re-export leak had the potential to break a consumer in a way no tooling caught.
Problem
The analytics package has no Python linting and legacy packaging:
No ruff/flake8/pylint config anywhere in the repo, and CI never runs against the Python code (deploy-analytics.yml only uploads the static gh-pages output).
Packaging is a bare setuptools setup.py with no pyproject.toml; dependencies are managed with pip + venv + a hand-pinned analytics/requirements.txt.
The star-import bug fixed in #4933 (report_elements.py re-exporting entities/_report_utils names, with fetch.py depending on the leak) is exactly what ruff's F403/F405 rules flag out of the box — it would have been caught at authoring time instead of costing an issue and a PR.
Suggested fix
Add a pyproject.toml to analytics/analytics_package and move the setup.py metadata into it (setuptools setup.py-only packaging is deprecated, and ruff config wants a pyproject.toml anyway).
Add a CI step to run-checks.yml (or a small dedicated workflow) that runs ruff on changes under analytics/** — a linter nobody runs is decoration.
Migrate dependency management to uv: uv.lock replacing the hand-pinned analytics/requirements.txt, and update analytics/readme.md setup instructions accordingly.
Verification
ruff check passes locally and in CI; a deliberately introduced from x import * usage fails the check.
Fresh-venv generate_static_site.py run including historic_data_path, per the chore: retire legacy analytics formats — tracking #4913 verification convention, to confirm packaging changes didn't break the editable install.
Follow-up from #4927 / #4933, where a star-import re-export leak had the potential to break a consumer in a way no tooling caught.
Problem
The analytics package has no Python linting and legacy packaging:
deploy-analytics.ymlonly uploads the staticgh-pagesoutput).setup.pywith nopyproject.toml; dependencies are managed with pip +venv+ a hand-pinnedanalytics/requirements.txt.The star-import bug fixed in #4933 (
report_elements.pyre-exportingentities/_report_utilsnames, withfetch.pydepending on the leak) is exactly what ruff's F403/F405 rules flag out of the box — it would have been caught at authoring time instead of costing an issue and a PR.Suggested fix
pyproject.tomltoanalytics/analytics_packageand move thesetup.pymetadata into it (setuptoolssetup.py-only packaging is deprecated, and ruff config wants apyproject.tomlanyway).Frules (F403/F405 are the ones that would have caught chore: make analytics package public exports explicit (remove star-import leak) #4927); runruff checkandruff format --checkclean on the existing code, fixing or explicitly ignoring what surfaces.run-checks.yml(or a small dedicated workflow) that runs ruff on changes underanalytics/**— a linter nobody runs is decoration.uv.lockreplacing the hand-pinnedanalytics/requirements.txt, and updateanalytics/readme.mdsetup instructions accordingly.Verification
ruff checkpasses locally and in CI; a deliberately introducedfrom x import *usage fails the check.generate_static_site.pyrun includinghistoric_data_path, per the chore: retire legacy analytics formats — tracking #4913 verification convention, to confirm packaging changes didn't break the editable install.