EMRY-068: ship the emry CLI in the wheel #120
No reviewers
Labels
No labels
blocked
bug
compat
docs
documentation
duplicate
emry-cli
emry-core
emry-engine
emry-ingest
emry-py
emry-store
emry-tui
emry-web
enhancement
good first issue
gpu-compute
help wanted
hpc
infra
integrations
invalid
needs-design
P0-blocker
P1-core
P2-enhanced
P3-future
performance
pull-request
python
pytorch
question
rust
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
femboy/emry!120
Loading…
Reference in a new issue
No description provided.
Delete branch "emry-cli-in-wheel"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The 0.2.0 wheel shipped only the SDK +
emry._nativeextension. Theemrycommand is a Rust binary (emry-cli) that maturin never bundled, and there was no console script — sopip install emrygave noemry watch/web/compare/export, and the SDK's live dashboard (which launchesemry) silently degraded.Fix (ruff/uv-style bundling)
scripts/build-cli.shcompilesemryintopython/emry/_bin/at wheel-build time;[tool.maturin] includebundles it (wheel only — the sdist rebuilds from source).emry = emry._cli:main+python -m emry: the shim execs the bundled binary.live.pyresolves the bundled binary directly (works even when the venvbin/isn't on PATH; falls back toemryon PATH for source installs).run(name=...)alias for the positional run name (papercut #3).wheelsjob builds the CLI and verifiesemry --version+python -m emryfrom a clean--no-indexinstall — so the bundling is proven on every PR.manylinux_2_28container (cmake+perl for rustls/aws-lc-rs) so the bundled binary matches the wheel's glibc floor.Verified locally: built the wheel, installed into a clean venv,
emry --version→emry 0.2.1,python -m emry runs --helpworks, SDK imports,name=alias + both/neither error paths correct. Python coverage 94.4%.Closes #119