Installing and testing Signet from a checkout (macOS + Linux), and why pipx install signet-gateway does not work yet
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
There is currently no way to install a released Signet: `signet-gateway` has never
been published to PyPI, so the `pipx install signet-gateway` line in the README
cannot work yet. Installing from a source checkout does work, including on macOS
arm64, and the fake-only demo exercises the real gateway pipeline end to end.
This issue records the verified install-and-test path so it is written down while
the release is still in flight, and notes the two places macOS differs from Linux.
## Why `pipx install signet-gateway` fails today
Two independent reasons, both on `main` right now:
1. **Nothing is published.** `pypi.org/pypi/signet-gateway/json` and
`/simple/signet-gateway/` both return 404, and the repo has no releases or tags.
2. **The build could not produce a publishable wheel.** `hatch_build.py:21-22`
derives the wheel tag from `sysconfig.get_platform()`:
```python
platform_tag = sysconfig.get_platform().replace("-", "_").replace(".", "_")
build_data["tag"] = f"py3-none-{platform_tag}"
```
On Linux that yields `py3-none-linux_x86_64`. **PyPI rejects bare `linux_*`
platform tags** — they require `manylinux_*`/`musllinux_*` or `any`. There is no
`auditwheel` step, and the distribution has no compiled extensions, so the tag
was both unpublishable and unnecessary. A `v*.*.*` tag push would have failed at
the `uv publish` step in `release.yml` *after* CI verification, both wheel builds,
SBOM generation, Sigstore signing, and both attestation steps had already
succeeded.
Note that CI's only tag assertion (`ci.yml:282`) rejects the *universal* tag:
```
*-none-any.whl)
echo "POSIX-only Signet was built as a universal wheel" >&2
exit 1
```
A `linux_x86_64` tag passes that trivially, so the gate was guarding the exact
opposite of the invariant that matters for publishing.
Also relevant to the README's one-liner: `main` is version `0.1.0b1`, a PEP 440
pre-release. Even once published, `pip install signet-gateway` resolves nothing for
a pre-release without `--pre`.
## Installing from a checkout (works today, macOS included)
Signet requires **Python 3.12** exactly (`requires-python = ">=3.12,<3.13"`). There
is no `[tool.uv]` sources section, so plain `pip`/`pipx` can build it — `uv` is only
needed for development.
```bash
git clone https://github.com/bee-san/Signet
cd Signet
# Homebrew Python 3.12 on macOS; adjust if you use pyenv or python.org
brew install python@3.12
python3.12 -m venv ~/signet
~/signet/bin/pip install .
~/signet/bin/signet --version
```
`pipx` works too and is nicer for a CLI:
```bash
pipx install --python "$(brew --prefix python@3.12)/bin/python3.12" .
```
Installing pulls a fully pinned 69-package runtime closure. On macOS the
Linux-only dependencies are correctly excluded by their environment markers
(`jeepney` and `secretstorage` are gated to `sys_platform == 'linux'`).
## Testing it: the fake-only demo
This is the useful part — it runs the **real** gateway pipeline with fake
identities and network-disabled providers, and needs no credentials, no Tailscale,
and no external services:
```bash
~/signet/bin/signet demo init --data-dir ~/.signet-demo
~/signet/bin/signet demo smoke --data-dir ~/.signet-demo
~/signet/bin/signet demo seed-request --data-dir ~/.signet-demo
~/signet/bin/signet demo serve --data-dir ~/.signet-demo
```
Expected output from `smoke` and `seed-request`:
```json
{"aliases":["fastmail","whatsapp","approvals"],"database":"ok","mode":"fake-only","network_provider_calls":0,"status":"ok"}
{"created":true,"request_id":"req_...","service":"fastmail","state":"pending_approval","status":"ready_for_review","tool":"send_email"}
```
`state: pending_approval` with `network_provider_calls: 0` is the core guarantee
demonstrating itself: a realistic fake email went through canonicalization,
encryption, the SQLite state machine, and policy evaluation, and the downstream
mutation stayed unsent.
Two constraints from the code, worth knowing before you run it: `demo init` refuses
any existing destination and never creates parent directories, and private demo
paths reject symlinked ancestors — so pass a physical path (`cd ~ && pwd -P`) if
`$HOME` is a symlink. `seed-request` must run while the server is stopped.
Read-only commands that also work immediately: `signet doctor`, `signet status`,
`signet --help`. On a machine with no setup, `doctor` reports the missing journal
and exits 0.
## Two macOS-specific notes
**1. `signet setup` needs Tailscale installed.** The full packaged setup resolves a
`tailscale` binary from four reviewed absolute paths
(`setup_platform.py:103-108`), the first being
`/Applications/Tailscale.app/Contents/MacOS/Tailscale`. Without one it fails closed
with `external setup command is unavailable or unsafe` and writes nothing. This is
by design — the private origin is a Tailscale node on HTTPS 8443 — but the error
text does not name the missing dependency, which makes it hard to diagnose. Worth a
clearer message.
**2. WhatsApp is Linux-only; Fastmail and the demo are not.** The reviewed `wacli`
process boundary is descriptor-bound through `/proc/self/fd`
(`reviewed_process.py:15`), which does not exist on macOS, so WhatsApp activation is
fail-closed there. This does **not** affect the demo or general use: the one other
`/proc/self/fd` reference (`private_paths.py:710-719`) is a `_LINUX`-guarded fallback
behind a plain `os.fchmod`, so directory hardening works normally on macOS.
## Verified
Installed and exercised on Linux x86_64 with CPython 3.12.13 — the demo output
above is real, not illustrative. All three sources install and run cleanly:
- the source checkout
- the built sdist
- the built `py3-none-any` wheel
A fresh clone of `main` reports `signet 0.1.0b1`; the `0.1.0` in my local runs is
from a branch that also carries the version bump, so do not be surprised by the
difference.
macOS arm64 is covered in CI by the `macos-15` job, which builds and smoke-tests
the wheel; I have not personally run the demo on macOS.
## Suggested fixes
- Emit one `py3-none-any` wheel; the distribution is pure Python. Keep POSIX
enforcement in the `sys_platform` dependency markers plus a runtime guard in
`signet.app:main`, and invert the CI/release tag assertion so it requires
`py3-none-any` rather than forbidding it.
- Cut a non-pre-release `0.1.0` so the documented `pip`/`pipx` one-liner resolves
without `--pre`.
- Add a TestPyPI rehearsal (`workflow_dispatch`) so the publish step can be
exercised without burning a real tag. Gating on the event name rather than an
input means a manual run can never reach production PyPI.
- Until something is published, change the README's `pipx install signet-gateway`
to the checkout instructions above, so the documented path is one that works.
- Name the missing binary in the Tailscale-resolution error.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with hatch_build.py:21-22, ci.yml:282, release.yml, and the README install instructions; compare the current wheel tags and documented commands with the verified checkout and demo paths. Also inspect setup_platform.py:103-108 for the macOS diagnostic. Done means the packaging and release checks, install guidance, and missing-Tailscale error consistently reflect the supported behavior, with the stated install and demo commands still passing.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, python
- Domain
- build-system, ci-cd, documentation, release
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100