Skip to content

fix(packaging): include root build.rs in sdist; make it graceful outside a git tree#107

Merged
ssmichael1 merged 2 commits into
mainfrom
fix/sdist-build-rs
May 25, 2026
Merged

fix(packaging): include root build.rs in sdist; make it graceful outside a git tree#107
ssmichael1 merged 2 commits into
mainfrom
fix/sdist-build-rs

Conversation

@ssmichael1
Copy link
Copy Markdown
Owner

@ssmichael1 ssmichael1 commented May 25, 2026

Summary

  • The PyPI 0.17.0 sdist failed to include the root build.rs because MANIFEST.in listed python/build.rs but not the top-level one. cargo build from the sdist (conda-forge, plain pip install ./satkit-0.17.0.tar.gz, etc.) panicked with "environment variable GIT_HASH not defined at compile time" — that env var is set by the root build.rs, which simply wasn't shipped.
  • Two small fixes: add include build.rs to MANIFEST.in, and rewrite the root build.rs to fall back to "unknown" for GIT_HASH / GIT_TAG when there's no .git/ (matching the pattern already in python/build.rs).
  • Surfaced while validating the in-progress conda-forge recipe locally — but the fix is generally useful for any non-git sdist consumer.

Test plan

  • cargo build --release and cargo test --release on the branch — all 226 tests pass
  • python -m build --sdist produces a tarball that includes build.rs at the root
  • Local conda build against the fixed sdist compiles the satkit Rust extension cleanly and the Moon-position smoke test passes (398,940,201 m)

🤖 Generated with Claude Code

ssmichael1 and others added 2 commits May 25, 2026 07:42
@ssmichael1 @claude
fix(packaging): include root build.rs in sdist and make it graceful o…
a64072c 
…utside a git tree

The PyPI 0.17.0 sdist failed to include the root `build.rs` because
`MANIFEST.in` listed `python/build.rs` but not the top-level one. As a
result, `cargo build` from the sdist (e.g. conda-forge builds, or any
`pip install` of the source tarball) panicked with "environment
variable GIT_HASH not defined at compile time" — the root build.rs sets
those env vars and was simply absent.

Two fixes, both small:

* Add `include build.rs` to `MANIFEST.in` so the sdist ships it.
* Make `build.rs` use the same `.ok().and_then(...).unwrap_or_else(||
  "unknown".to_string())` pattern that `python/build.rs` already uses,
  so sdist / tarball builds where there's no `.git/` succeed with
  `GIT_HASH=unknown` / `GIT_TAG=unknown` rather than panicking.

Surfaced while validating the conda-forge recipe locally.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ssmichael1 @claude
style: apply cargo fmt --all (CI lint fix)
2c0100d 
Fixes the rustfmt lint that's been failing on main since PR #106 merged.
Six of the seven files were already unformatted on main; the seventh
(build.rs) is from this branch's own changes. Pure-formatting commit —
no logic changes; all tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ssmichael1 added a commit that referenced this pull request May 25, 2026
@ssmichael1 @claude
style: apply cargo fmt --all (inherited from main)
1edb3de 
Same lint-fix as PR #107: rustfmt has been failing on main since PR
#106 merged. Whichever of #107 / #108 merges first will clear the
duplicate fix from the other.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ssmichael1 ssmichael1 merged commit d963ba7 into main May 25, 2026
5 checks passed
ssmichael1 added a commit that referenced this pull request May 25, 2026
@ssmichael1 @claude
fix(pyi): drop fabricated 6-arg from_datetime overload (#105) (#108)
2779178 
* fix(pyi): drop fabricated 6-arg from_datetime overload (#105)

The `.pyi` stub claimed two `time.from_datetime` overloads, but only one
matched a real Rust binding (the single-arg `datetime.datetime` form at
`python/src/pyinstant.rs:485`). The 6-arg variant
`from_datetime(year, month, day, hour, min, sec, scale)` was a
stub-file fabrication — no Rust function backs it, so calls like
`time.from_datetime(2024, 3, 1, 12, 0, 0.0)` blew up at runtime with
"takes 1 positional argument but 6 were given" while the language
server happily auto-completed the broken signature.

Fix is `.pyi`-only:
* Delete the bogus 6-arg `@overload` block.
* Drop the now-redundant `@typing.overload` decorator from the
  surviving single signature.

Users wanting the 6-arg constructor: that already exists at runtime
and in the stubs as `time.from_gregorian(year, month, day, hour, min,
sec)`.

Fixes #105.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* style: apply cargo fmt --all (inherited from main)

Same lint-fix as PR #107: rustfmt has been failing on main since PR
#106 merged. Whichever of #107 / #108 merges first will clear the
duplicate fix from the other.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ssmichael1 added a commit that referenced this pull request May 25, 2026
@ssmichael1 @claude
Add conda-forge recipes for satkit + satkit-data (#113)
0a2606f 
* feat: conda-forge recipes for satkit and satkit-data

Adds `recipes/conda/satkit/` and `recipes/conda/satkit-data/` —
meta.yaml drafts (and a small smoke-test script for satkit) for
submission to conda-forge/staged-recipes.

Two key design choices encoded in the recipes:

* The conda `satkit-data` build is intentionally a different payload
  from the PyPI sibling at the same version: it ships JPL DE421
  (`lnxp1900p2053.421`, ~13 MB, 1900–2053) instead of DE440 full
  (~98 MB). DE440 squeaks under conda-forge's 100 MB soft cap but
  reviewers grumble; DE421's accuracy is indistinguishable for
  Earth-orbit work (Sun/Moon positions agree sub-meter at modern
  epochs). Callers who need the longer span can install DE440 via
  `satkit.utils.update_datafiles()` post-install — autodetect prefers
  it once present.
* EOP-All.csv and SW-All.csv are NOT bundled; CelesTrak regenerates
  them daily and a stale snapshot would mislead users.
  `update_datafiles()` fetches them on demand.

Both recipes were built and the smoke test passed locally —
satkit-data installs as a conda dep, satkit's autodetect resolver
finds the DE421 file inside it, and a Python query for the Moon's
geocentric position returns ~399,000 km.

The satkit recipe's `source:` URL currently points at a local sdist
for validation; it will be flipped to the PyPI URL (and the sha256
updated) once 0.17.1 ships with the build.rs / MANIFEST.in fix from
the previous commit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* recipes(conda): bump satkit to 0.18.0; switch source to PyPI

* `recipes/conda/satkit/meta.yaml` — version `0.17.0` → `0.18.0`;
  source URL flipped from the local `file:///tmp/...` validation path
  to the canonical PyPI sdist; sha256 updated against the published
  0.18.0 tarball (`9af912f7...`). The build.rs sdist-inclusion fix
  from PR #107 is part of 0.18.0, so the recipe builds cleanly
  straight from PyPI.
* `recipes/conda/README.md` — drop the "TODO sha256" caveat that's no
  longer applicable; document the `pip hash` refresh step for future
  version bumps.

Both recipes re-built and tested locally with conda-build 26.3.0:
satkit-data-0.9.0-py_0.conda (15 MB noarch) + satkit-0.18.0 with the
Moon-position smoke test green (398,940,201 m via DE421 inside the
conda-installed satkit-data).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@ssmichael1