astroceleste-engine
Astrological chart calculation on JPL ephemerides, in pure Rust.
It is the calculation core of Astroceleste. The same code runs on the server (Python bindings), in the desktop and mobile apps (native) and in the browser (WASM), so every platform computes the same chart down to the arcsecond.
Experimental (0.0.x): the API may change in any release. Pin an exact version.
Status: the complete chart pipeline is ported and matches the reference implementation on every golden chart: planets, lunar nodes, Chiron, Lilith, houses (Placidus, Whole Sign, Equal, Porphyry), aspects and orbs, fixed stars, Arabic parts, temperament, lunar status, horary charts (planetary hours from computed sunrise and sunset), transits, synastry and derived charts, with Python and WebAssembly bindings.
Usage
use ;
use ;
let mut kernels = new;
kernels.push;
let request = new;
let chart = calculate_chart?;
println!;
Charts serialize to the same JSON as the Astroceleste API. Other entry points:
calculate_horary_chart, calculate_transit_chart, calculate_synastry and
calculate_derived_chart. In the browser or on mobile, load the kernel from memory with
Spk::from_bytes.
Bindings
- Python (
pip install astroceleste-engine, CPython ≥ 3.12):Engine([kernel paths])with.chart(),.horary(),.transit(), plussynastry()andderived_chart(), returning plain dicts. See crates/astroceleste-engine-py. - JavaScript / WebAssembly (
npm install astroceleste-engine): the same API over kernels loaded from memory, for browsers and Node. See crates/astroceleste-engine-wasm.
Both are tested against the same golden fixtures as the Rust crate.
Layout
| Path | Content |
|---|---|
crates/astroceleste-engine |
the core library |
crates/astroceleste-engine-py |
Python bindings (PyO3, built with maturin) |
crates/astroceleste-engine-wasm |
WebAssembly bindings (wasm-bindgen, built with wasm-pack) |
tests/fixtures/*.json |
golden charts produced by the reference implementation, the acceptance spec |
tests/data/de440s_2000.bsp |
one-year excerpt of DE440s used by the tests |
scripts/fetch-kernels.sh |
downloads full JPL kernels into kernels/ (gitignored) |
scripts/make_spk_fixtures.py |
rebuilds the excerpt and the SPK reference states with jplephem |
scripts/make_reduction_fixtures.py |
stage-by-stage reference values from Skyfield |
scripts/gen_tables.py |
regenerates the embedded ΔT, nutation and Chiron tables |
Development
# Python bindings (in a virtualenv)
&&
# WebAssembly bindings (needs wasm-pack and the wasm32-unknown-unknown target)
Releasing
Releases are trunk-based: there are no release branches or release PRs. Pushing a
vX.Y.Z tag on main publishes that version.
- Commits on
mainfollow Conventional Commits (feat:,fix:,perf:,refactor:, … and!for breaking changes). While the version is 0.0.x,feat/fixbump the patch version and a breaking change bumps the minor version. - Prepare the release on
main: runrelease-plz update(or edit by hand) to bump the workspace version, the bindings'astroceleste-enginedependency version andCHANGELOG.md, then commit aschore: release vX.Y.Zand push. - Once CI is green, tag that commit and push the tag:
git tag vX.Y.Z && git push origin vX.Y.Z. - The
Releaseworkflow checks that the tag is onmain, matches the version inCargo.tomland has aCHANGELOG.mdentry. It then publishes the crate to crates.io, creates the GitHub Release from the changelog entry, and publishes the Python wheels (Linux x86_64/aarch64 glibc and musl, macOS universal2, Windows x64, sdist) to PyPI and the WebAssembly package to npm.
Protect v* tags with a tag ruleset so only maintainers can trigger a release.
All three registries use Trusted Publishing (OIDC), so no long-lived token is stored. crates.io and npm can only trust a workflow for a package that already exists, so the first release uses short-lived tokens instead:
- Create the
release,pypiandnpmenvironments in the repository settings (optionally with required reviewers). - crates.io: create an API token scoped to
publish-newandpublish-updatefor the crateastroceleste-engine, with a short expiry, and store it as theCARGO_REGISTRY_TOKENsecret of thereleaseenvironment. - npm: create a granular access token with publish rights and a short expiry, and store
it as the
NPM_TOKENsecret of thenpmenvironment. - PyPI: add a pending trusted publisher for project
astroceleste-engine(workflowrelease.yml, environmentpypi). No token is needed. - Push the
vX.Y.Ztag for the version inCargo.toml. - Once the packages exist, add the trusted publisher on crates.io (crate settings →
Trusted Publishing: this repository, workflow
release.yml, environmentrelease) and on npm (package settings: workflowrelease.yml, environmentnpm). Then delete both secrets and revoke the tokens. The workflow prefers OIDC whenever it is available.
Ephemerides
The engine reads NASA JPL SPK kernels (DE440s by default, DE441 for dates outside 1849–2150). Dates outside the loaded kernels are reported as errors, never approximated.
License
Licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE)
- MIT license (LICENSE-MIT)
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this work, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.