goodboy/tractor

Tractor owns the registrar mechanism and actor lookup APIs, but the client-side policy for choosing registrar contacts is still spread across actor state, runtime vars and downstream wrappers. Piker currently fills that gap with a process-global Registry.addrs, scoped overrides, address normalization, mismatch diagnostics and service-oriented wrappers around tractor.find_actor(). PR #505 made the duplication more visible by requiring Piker to normalize legacy config pairs against tractor's canonical tagged address forms. PR #493 also changes the design space: TIPC can resolve service names directly and publish topology events from the kernel. Those facilities should be optional discovery sources that compose with the portable registrar path, not a second hard-coded registry system. This issue distills a transport-aware discovery-client contract from those concrete downstream and TIPC use cases. Separate the three planes, Discovery currently conflates three independent jobs: presence

Context tractors tipc backend (#378, PR #493) ships an interim, str-only multiaddr grammar because there is no registered /tipc protocol in the multiaddr table: /tipc/<stype>/<instance>/<scope> parse_maddr() has to special-case that prefix before handing anything to Multiaddr(), which would otherwise reject the unregistered name outright. The composed form is the real target Our intended multihost deployment is TIPC over a wg mesh (#502), so the address that actually matters is the composed one, mirroring what py-multiaddr#108 landed for wg + tcp: # tcp over wg (already parses, per #108) /ip4/<pub>/udp/51820/wg/u<key>/ip4/10.0.11.1/tcp/1616 \____ wg bearer ________/\_key_/\___ tractor ep ____/ # tipc over wg (what we want) /ip4/<pub>/udp/51820/wg/u<key>/tipc/<stype>/<instance>/<scope> \____ wg bearer ________/\_key_/\______ tractor ep ________/ Note the structural difference worth raising in the spec proposal: the tcp inner segment repeats an /ip4/ because a tcp endpoint is located;

Follow-up to #475, which restores import tractor on Windows and re-adds an informational windows-latest TCP CI leg. This issue tracks making that leg fully green and required. Current evidence PR #475 head 40be587c completed the full Windows suite in CI: 297 passed 37 skipped 53 failed 2 errors 6 xfailed 2 xpassed Run: https://github.com/goodboy/tractor/actions/runs/32045336520/job/95431850213 The required smoke contract passed: import tractor succeeds and HAS_UDS is False. The previous branch baseline already had 50 failed and 2 errors, so the remaining work is broad platform cleanup rather than a rebase regression. Package A: test harness and capability selection Migrate tests/test_docs_examples.py from legacy Testdir path arithmetic to pytester.path. Keep supported examples as real subprocess E2E tests; skip only infected-asyncio and UDS examples by capability. This currently accounts for 20 failures. Replace the signal.alarm() wakeup-socketpair guard with a disposable child in

Motivation PR #460 stood up the new docs site (pydata theme, d2 diagrams, tested examples) as a scaffold + middle ground — the structure, wiring, and current-API correctness are in, but substantial prose still needs filling / refining across the guides. This issue tracks that content pass so #460 can land immediately as the scaffold. Scope Refine + flesh out the written content across the docs tree (docs/). Fill in per-page bullet notes as the refinement passes happen: (TODO @goodboy — bullet notes per page/guide) update the caps-based-msging section to include #365 which is the primary most recent issue which protos out our longer term type-annot-driven pld_spec API. also point to our current test suites which i'm pretty already demo a higher-level approach then using tractor.msg._ops.limit_plds()? also link in the new enc/dec_hook() factor PR #376 (from @guilledk) as the (potential) longer term refined public API. it's a draft from the https://github.com/goodboy/trac

Originally claiming in its review comment of #342 that, The get_peer_pid function uses magic numbers (getsockopt(0, 2)) without named constants. On macOS, level 0 is SOL_LOCAL and option 2 is LOCAL_CREDS (not LOCAL_PEERCRED=1). The LOCAL_CREDS option only enables credential passing on future connections rather than retrieving the peer PID. On macOS, obtaining the peer PID requires getsockopt(SOL_LOCAL=0, LOCAL_PEERCRED=1, buflen) which returns a xucred struct (containing cr_uid, cr_gid, etc. but NOT a PID directly). As a result, this function is likely returning None on macOS (silently falling through the exception handler) rather than actually retrieving the peer PID — callers then use None as maybe_pid in UDSAddress. The referenced SO answer (https://stackoverflow.com/a/67971484) is about Linux. Consider documenting clearly that this always returns None on macOS, or use an alternative approach such as reading the peer credentials via ctypes. with the suggestion that we change, de