The checkout is now astrape/astrape-dashboard, not astrape/astrape-dashboard/<package>. The package
contents move to the repository root and pyproject maps the package name to
'.' via package-dir, with the subpackages listed explicitly.
The systemd units move out to /srv/astrape/deploy/systemd, outside every
repository, because they describe this deployment rather than any one
component.
Verified both install modes: editable, which is how the deployment runs, and
a plain wheel install, which is what the container build does.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
_webui re-imports and reloads its dependencies on every request. The repo
split left two entries wrong: both the weather and station display slots
pointed at astrape_oracle.classes.datasets, so the dataclasses were reloaded
twice and the renderers -- which moved to this repo -- were never reloaded at
all. Editing a display would have had no effect until a restart.
The datasets module keeps its own slot, since the stores return those types.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The repos now sit directly under /srv/astrape, which is also every unit's
WorkingDirectory. Python prepends the working directory to sys.path for
'python -m', so the gibil checkout at /srv/astrape/gibil was shadowing the
installed package: the repo root has no __init__.py, so 'gibil' resolved as a
namespace portion with __file__ None, and submodules only resolved because a
namespace path recomputes itself on access.
Everything is installed into the venv, so nothing needs the working directory
on sys.path. WorkingDirectory still matters for env/ and models/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Each repo carries the units for the daemons it owns. WorkingDirectory stays
/srv/astrape so env/ and models/ resolve, while the code comes from the
editable installs under repos/.
The old astrape-db.service was misnamed -- it runs the weather forecast
ingest, and collided with what would have been an astrape-db repo. It is
astrape-weather-forecast.service here.
The training unit forces ATEN_CPU_CAPABILITY=default, because this host has no
AVX2 and torch otherwise dies with SIGILL in Adam, and caps threads with Nice
so a nightly run does not starve the 5-second Modbus poll.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The web frontend: the UI itself, the oracle, weather, station and
quality renderers, and the serving daemon.
The weather and station display modules were each split in two. The
dataclasses went to astrape-oracle with the stores that return them;
only the rendering stayed here, so the dependency runs dashboard ->
oracle -> ems -> gibil with no cycle.
Extracted from a single repository where the forecasting engine, the
database plumbing, the hardware client, the ingest daemons and the web
UI all imported each other freely. Verified that every module imports
with gibil resolved from its own installed checkout.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rpotter6298