pyvisa-rs 0.1.1__tar.gz

pyvisa_rs-0.1.1/.cargo/config.toml

@@ -0,0 +1,2 @@
+[alias]
+xtask = "run --package xtask --"

pyvisa_rs-0.1.1/.claude/skills/ensure-parity/SKILL.md

@@ -0,0 +1,243 @@
+---
+name: ensure-parity
+description: Resolve a behavioural divergence between pyvisa-py and pyvisa-rs (or the rsvisa-rs crate). Use this whenever the user reports that the Rust port behaves differently from the vendored pyvisa-py reference — different discovery output, different read/write bytes, different error codes, different parsing, etc. The skill walks through reproducing the divergence, root-causing it inside `pyvisa-py/`, mirroring the upstream semantics in Rust, and adding regression coverage.
+---
+
+# Ensure pyvisa-py ↔ rsvisa-rs Parity
+
+The single load-bearing rule of this repo lives in `CLAUDE.md`:
+
+> **rsvisa-rs aims for 100% behavioural parity with pyvisa-py.** When you find
+> a divergence, the fix is to make rsvisa-rs match pyvisa-py — never to
+> special-case the reported symptom.
+
+This skill operationalises that rule. The user gives you code or a description
+showing pyvisa-py and pyvisa-rs disagreeing; you produce a repro, find the
+*root* upstream semantic, port it, and pin it down with a regression test.
+
+## Inputs to expect
+
+The user may hand over any of:
+
+- A Python snippet using `pyvisa.ResourceManager("@py")` whose output differs
+  from the same snippet using `"@rs"`.
+- A Rust snippet calling `rsvisa_rs::ResourceManager` directly.
+- A discovery query (`cargo xtask visa-discovery <QUERY>`) returning different
+  resource sets between the two backends.
+- A bug description ("`*IDN?` returns extra bytes on `@rs`", "`USB0::…` parses
+  but fails to open", "discovery is missing my Prologix interface", …).
+
+If the user description is vague, ask **once** for the smallest snippet that
+reproduces the divergence, then proceed — do not stall.
+
+## The five stages
+
+Work through these stages in order. Track them with the task tool so progress
+is visible.
+
+### 1. Reproduce the divergence
+
+Goal: a deterministic, hardware-free repro that produces *different* outputs
+on the two backends. Prefer in this order:
+
+1. **A failing Rust unit test** in the relevant module (e.g.
+   `src/resource.rs`, `src/serial.rs`, `src/usb.rs`, `src/tcpip.rs`,
+   `src/vxi11.rs`). Use the existing `#[cfg(test)] mod tests` patterns and
+   pure inputs (strings, byte slices) wherever possible.
+2. **The discovery xtask**, when the divergence is about which resources
+   appear from `list_resources`:
+
+   ```sh
+   cargo xtask visa-discovery "<QUERY>"
+   cargo xtask visa-discovery --check "<QUERY>"   # non-zero on mismatch
+   ```
+3. **The side-by-side Python script**, when the divergence is visible only
+   through PyVISA's higher-level API (timeouts, termchars, status codes
+   returned to Python):
+
+   ```sh
+   cd pyvisa-rs && uv run \
+     --with pyvisa --with pyserial --with pyusb \
+     --with libusb-package --with zeroconf --with pyvisa-py \
+     --reinstall-package pyvisa-rs \
+     examples/discovery.py "<QUERY>"
+   ```
+
+   Or, for arbitrary I/O experiments, write a one-off script that opens the
+   resource through both `@py` and `@rs`, performs the same calls, and prints
+   both transcripts. Run with the same `uv run --with …` set as above.
+4. **A `tests/pyvisa_py_parity.rs`-style integration test** when hardware or
+   live Python is genuinely required. These are `#[ignore]`d by default —
+   note in the test which env var the user has to set to opt in.
+
+Capture the *exact* observed difference (bytes, status codes, lists of
+strings) before moving on. If you only have a human description and cannot
+reproduce, say so explicitly and ask for more detail — do not invent a fix.
+
+### 2. Root-cause inside pyvisa-py
+
+This is the most important stage. The repo vendors pyvisa-py at
+`pyvisa-py/pyvisa_py/` *as the source of truth*. Module names line up:
+
+| Concern                        | pyvisa-py                                | rsvisa-rs       |
+|--------------------------------|------------------------------------------|-----------------|
+| Resource name parsing/filter   | `pyvisa-py/pyvisa_py/highlevel.py`, plus upstream `pyvisa.rname` (read from the installed `pyvisa` package via `python -c "import pyvisa.rname, inspect; print(inspect.getsourcefile(pyvisa.rname))"`) | `src/resource.rs` |
+| Session dispatcher             | `pyvisa_py/highlevel.py`, `pyvisa_py/sessions.py` | `src/session.rs` |
+| Serial / ASRL                  | `pyvisa_py/serial.py`                    | `src/serial.rs` |
+| TCPIP SOCKET / INSTR           | `pyvisa_py/tcpip.py`                     | `src/tcpip.rs`  |
+| USB INSTR / RAW                | `pyvisa_py/usb.py`, `pyvisa_py/protocols/usbtmc.py`, `usbraw.py`, `usbutil.py` | `src/usb.rs` |
+| VXI-11 RPC                     | `pyvisa_py/protocols/vxi11.py`, `rpc.py`, `xdrlib.py` | `src/vxi11.rs`, `src/rpc.rs` |
+| Constants / attribute IDs      | upstream `pyvisa.constants`              | `src/constants.rs` |
+| Common helpers                 | `pyvisa_py/common.py`                    | `src/common.rs` |
+
+Workflow:
+
+1. **Open the corresponding pyvisa-py file** for the divergence area. Read
+   the full function or class, not just the line that seems relevant. Note
+   the *general* rule, not the specific case the user hit (e.g. "matches via
+   `re.match` with `?` → `.` substitution", not "this one resource string
+   isn't matched").
+2. **Trace dependencies into upstream pyvisa** if pyvisa-py delegates to it
+   (e.g. `pyvisa.rname.filter`, `pyvisa.constants.StatusCode`,
+   `pyvisa.errors`). The vendored tree only contains pyvisa-py itself, so
+   look at the installed pyvisa via Python introspection:
+
+   ```sh
+   uv run --with pyvisa python -c \
+     'import pyvisa.rname, inspect; print(inspect.getsourcefile(pyvisa.rname)); print(inspect.getsource(pyvisa.rname.filter))'
+   ```
+3. **State the upstream semantic out loud** before you write any Rust. A
+   one-paragraph "pyvisa-py does X because Y" note makes it obvious whether
+   the planned Rust change actually matches — and is worth saving as a code
+   comment if the rule is non-obvious (see the comment in
+   `src/resource.rs::filter` for the shape).
+4. **Watch for upstream bugs / inconsistencies.** Per `CLAUDE.md`: when
+   pyvisa-py is itself wrong, *match it anyway* and flag the divergence to
+   the user. Don't silently improve on the reference; that breaks parity in
+   the other direction.
+
+### 3. Implement the Rust fix
+
+- Edit the matching file from the table above. Keep method names in
+  snake_case mirrors of the Python names (`open_default_resource_manager`,
+  `list_resources`, `read_stb`, `gpib_command`, …) — don't rename them.
+- No backwards-compat shims, no speculative abstractions. If the new
+  semantic obsoletes existing code, delete the old code.
+- Only add a code comment when the WHY is non-obvious — typically a pointer
+  to the pyvisa-py quirk being mirrored. The existing
+  `src/resource.rs::filter` comment is the template:
+
+  > Mirrors pyvisa.rname.filter: VISA queries are compiled as a
+  > case-insensitive regex (with `?` rewritten to `.`) and matched against
+  > each resource string with prefix-anchored semantics — i.e. Python's
+  > `re.match`, not whole-string `re.fullmatch`.
+
+- After editing, run `cargo cleanup` (per the global instructions) to
+  auto-fix and format.
+
+### 4. Lock in regression tests
+
+Tests should encode the *general* upstream semantic, not just the failing
+case. The parity rule is what's being protected.
+
+- **Unit tests** in the same `#[cfg(test)] mod tests` block as the changed
+  code. Cover the rule and its corners (case-insensitivity, empty input,
+  alternation, anchoring, etc.) — see `src/resource.rs` `filter` tests for
+  the right granularity.
+- **Discovery diff** is automatic via `cargo xtask visa-discovery --check`,
+  but if the change affects discovery, run it and confirm both backends
+  agree.
+- **Integration test** in `tests/pyvisa_py_parity.rs` *only* when the rule
+  can only be observed through a live Python session or real hardware.
+  Mark with `#[ignore = "…"]` and document the env var in `docs/testing.md`
+  if a new one is introduced.
+
+Before declaring done, run:
+
+```sh
+cargo cleanup
+cargo test
+cargo xtask visa-discovery --check   # only if discovery may be affected
+```
+
+For divergences only visible through the PyO3 binding, also run the
+discovery script with `--reinstall-package pyvisa-rs` to ensure uv rebuilds
+the wheel against your Rust changes (uv's wheel cache does not invalidate on
+Rust source edits — flag this if `@rs` results look stale).
+
+### 5. Verify full parity
+
+Stage 4 covers the *specific* rule with regression tests. This stage proves
+that the originally-reported divergence — and any neighbouring behaviour —
+actually agrees end-to-end between `@py` and `@rs`. Don't skip it: a fix
+that passes the new unit tests but still shows different output in the
+user's repro is not done.
+
+Run both backends against the same inputs and compare:
+
+1. **Re-run the stage-1 repro on the fixed code.** Whatever produced the
+   original divergence (xtask, side-by-side script, Python snippet, Rust
+   test) must now show identical output. If the repro was a Python snippet,
+   run it with both `pyvisa.ResourceManager("@py")` and `"@rs"` in the same
+   process and diff the results.
+2. **Widen the comparison.** Run at least one of the broader cross-backend
+   checks so you catch collateral damage:
+
+   ```sh
+   cargo xtask visa-discovery --check        # discovery sets must match
+   cargo xtask visa-discovery --check "<QUERY>"  # plus the query from the bug
+   ```
+
+   And, for I/O-shaped divergences, the PyVISA-level side-by-side:
+
+   ```sh
+   cd pyvisa-rs && uv run \
+     --with pyvisa --with pyserial --with pyusb \
+     --with libusb-package --with zeroconf --with pyvisa-py \
+     --reinstall-package pyvisa-rs \
+     examples/discovery.py --check
+   ```
+
+   The `--reinstall-package pyvisa-rs` flag is mandatory after Rust edits;
+   without it uv serves a stale cached wheel and `@rs` will appear
+   unchanged.
+3. **If hardware is in scope**, run the relevant `tests/pyvisa_py_parity.rs`
+   case with `RSVISA_PARITY_RESOURCE` / `RSVISA_SERIAL_RESOURCE` set:
+
+   ```sh
+   RSVISA_PYTHON="uv run --with pyvisa --with pyserial --with pyusb \
+     --with libusb-package --with zeroconf python" \
+     cargo test --test pyvisa_py_parity -- --ignored
+   ```
+
+4. **Iterate.** If any of the above still shows divergence — even a
+   different one from what the user reported — go back to stage 2, find the
+   *new* upstream rule that's not being mirrored, port it, add a test, and
+   come back here. Repeat until every cross-backend check produces
+   byte-identical output (modulo intentionally-flagged pyvisa-py bugs).
+5. **Only when everything matches, report back.** Keep it short (1–2
+   sentences):
+   - The upstream pyvisa-py rule(s) you mirrored, with file:line refs.
+   - Files changed in rsvisa-rs and which tests now cover them.
+   - Output from the verification commands you ran ("xtask discovery: no
+     diff; example/discovery.py: no diff").
+   - Any upstream bug you intentionally matched and want the user to know
+     about.
+
+## Anti-patterns to avoid
+
+- **Special-casing the reported symptom.** If a single resource string used
+  to be misfiltered, don't add an exception for that string — fix the rule.
+- **Inventing a "better" behaviour.** Even if pyvisa-py's choice is weird,
+  parity is the goal. Surface the weirdness to the user as a note; don't
+  silently deviate.
+- **Skipping the pyvisa-py read.** "I think it probably does X" is not a
+  substitute for opening the file. The repo vendors the source for a
+  reason.
+- **Reading only the failing path.** Read the whole function so the test
+  you write covers the semantic, not the example.
+- **Forgetting `--reinstall-package pyvisa-rs`** when iterating through the
+  PyO3 bindings via `uv run`. Stale wheels are the most common false
+  negative in this repo.
+- **Renaming public API.** Snake-case mirrors of pyvisa-py's Python names
+  are deliberate; matching them is part of parity.

pyvisa_rs-0.1.1/.github/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.1.1"
+}

pyvisa_rs-0.1.1/.github/release-please-config.json

@@ -0,0 +1,28 @@
+{
+  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
+  "release-type": "simple",
+  "include-component-in-tag": false,
+  "include-v-in-tag": true,
+  "bump-minor-pre-major": true,
+  "bump-patch-for-minor-pre-major": true,
+  "draft": false,
+  "prerelease": false,
+  "packages": {
+    ".": {
+      "package-name": "pyvisa-rs",
+      "changelog-path": "CHANGELOG.md",
+      "extra-files": [
+        {
+          "type": "toml",
+          "path": "pyvisa-rs/pyproject.toml",
+          "jsonpath": "$.project.version"
+        },
+        {
+          "type": "toml",
+          "path": "pyvisa-rs/Cargo.toml",
+          "jsonpath": "$.package.version"
+        }
+      ]
+    }
+  }
+}

pyvisa_rs-0.1.1/.github/workflows/ci.yml

@@ -0,0 +1,100 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+env:
+  CARGO_TERM_COLOR: always
+  RUST_BACKTRACE: 1
+
+jobs:
+  rust:
+    name: Rust (${{ matrix.os }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Install Linux build deps
+        if: runner.os == 'Linux'
+        run: |
+          sudo apt-get update
+          sudo apt-get install -y libudev-dev libusb-1.0-0-dev
+
+      # PyO3's build script probes for a Python interpreter even when only
+      # checking/compiling the cdylib, so we set one up explicitly.
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install stable toolchain (clippy)
+        uses: dtolnay/rust-toolchain@stable
+        with:
+          components: clippy
+
+      - uses: Swatinem/rust-cache@v2
+
+      - name: cargo fmt
+        run: cargo fmt --all -- --check
+
+      - name: cargo clippy
+        run: cargo clippy --workspace --all-targets -- -D warnings
+
+      - name: cargo test
+        run: cargo test --workspace
+
+  wheels:
+    name: Wheel (${{ matrix.os }})
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Build wheel
+        uses: PyO3/maturin-action@v1
+        with:
+          working-directory: pyvisa-rs
+          command: build
+          args: --release --out dist
+          # auto picks the right manylinux container on Linux and is a no-op
+          # on macOS. The Linux container is RHEL-based so we install libusb /
+          # libudev via yum below.
+          manylinux: auto
+          before-script-linux: |
+            yum install -y libusbx-devel systemd-devel || \
+              (apt-get update && apt-get install -y libusb-1.0-0-dev libudev-dev)
+
+      - name: Smoke import
+        shell: bash
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install pyvisa
+          python -m pip install --no-index --find-links pyvisa-rs/dist pyvisa-rs
+          python - <<'PY'
+          import pyvisa
+          rm = pyvisa.ResourceManager("@rs")
+          print("debug info:", rm.visalib.get_debug_info())
+          PY
+
+      - name: Upload wheel
+        uses: actions/upload-artifact@v4
+        with:
+          name: wheel-${{ matrix.os }}
+          path: pyvisa-rs/dist/*.whl
+          if-no-files-found: error

pyvisa_rs-0.1.1/.github/workflows/lint-pr-title.yml

@@ -0,0 +1,38 @@
+name: lint pr title
+
+on:
+  pull_request:
+    branches: ["main"]
+    # Separate workflow so we can re-run when the title changes.
+    types: ["opened", "edited", "synchronize", "reopened"]
+
+concurrency:
+  group: "${{ github.workflow }}-${{ github.event.pull_request.number }}"
+  cancel-in-progress: true
+
+jobs:
+  lint-title:
+    name: conventional commit pr title
+    runs-on: ubuntu-latest
+    steps:
+      - name: Install commitlint
+        # This release broke the default config https://github.com/conventional-changelog/commitlint/releases/tag/v18.6.1
+        # After they fix the config-conventional package we can upgrade.
+        run: npm install -g @commitlint/cli@18 @commitlint/config-conventional@18.6.0
+      - name: Lint PR name
+        env:
+          TITLE: ${{ github.event.pull_request.title }}
+          CONFIG_FILE: ${{ runner.temp }}/commitlint.config.js
+          CONFIG: |
+            module.exports = { extends: ["@commitlint/config-conventional"] };
+        run: |
+          echo "$CONFIG" > "$CONFIG_FILE"
+          echo "$TITLE" | commitlint --config "$CONFIG_FILE" > >(tee "$RUNNER_TEMP/lint-output.txt")
+      - name: Display helpful error message
+        if: failure()
+        env:
+          TITLE: ${{ github.event.pull_request.title }}
+        run: |
+          echo "🚨 Your PR Title: \"${TITLE}\" did not pass linting" >> $GITHUB_STEP_SUMMARY
+          cat "$RUNNER_TEMP/lint-output.txt" >> $GITHUB_STEP_SUMMARY
+          echo "Please update it to follow conventional commit format: https://www.conventionalcommits.org/" >> $GITHUB_STEP_SUMMARY

pyvisa_rs-0.1.1/.github/workflows/release.yml

@@ -0,0 +1,109 @@
+name: Release
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release-please:
+    name: release-please
+    runs-on: ubuntu-latest
+    outputs:
+      release_created: ${{ steps.release.outputs.release_created }}
+      tag_name: ${{ steps.release.outputs.tag_name }}
+    steps:
+      - uses: googleapis/release-please-action@v4
+        id: release
+        with:
+          config-file: .github/release-please-config.json
+          manifest-file: .github/.release-please-manifest.json
+
+  wheels:
+    name: Wheel (${{ matrix.os }})
+    needs: release-please
+    if: needs.release-please.outputs.release_created == 'true'
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, macos-latest, windows-latest]
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ needs.release-please.outputs.tag_name }}
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Build wheel
+        uses: PyO3/maturin-action@v1
+        with:
+          working-directory: pyvisa-rs
+          command: build
+          args: --release --out dist
+          manylinux: auto
+          before-script-linux: |
+            yum install -y libusbx-devel systemd-devel || \
+              (apt-get update && apt-get install -y libusb-1.0-0-dev libudev-dev)
+
+      - name: Upload wheel
+        uses: actions/upload-artifact@v4
+        with:
+          name: wheel-${{ matrix.os }}
+          path: pyvisa-rs/dist/*.whl
+          if-no-files-found: error
+
+  sdist:
+    name: sdist
+    needs: release-please
+    if: needs.release-please.outputs.release_created == 'true'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          ref: ${{ needs.release-please.outputs.tag_name }}
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Build sdist
+        uses: PyO3/maturin-action@v1
+        with:
+          working-directory: pyvisa-rs
+          command: sdist
+          args: --out dist
+
+      - name: Upload sdist
+        uses: actions/upload-artifact@v4
+        with:
+          name: sdist
+          path: pyvisa-rs/dist/*.tar.gz
+          if-no-files-found: error
+
+  publish:
+    name: Publish to PyPI
+    needs: [release-please, wheels, sdist]
+    if: needs.release-please.outputs.release_created == 'true'
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/project/pyvisa-rs/
+    permissions:
+      id-token: write
+    steps:
+      - name: Download wheels and sdist
+        uses: actions/download-artifact@v4
+        with:
+          path: dist
+          merge-multiple: true
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1
+        with:
+          packages-dir: dist

pyvisa_rs-0.1.1/.gitignore

@@ -0,0 +1,2 @@
+/target
+/.claude/

pyvisa_rs-0.1.1/CHANGELOG.md

@@ -0,0 +1,8 @@
+# Changelog
+
+## [0.1.1](https://github.com/nominal-io/rsvisa-rs/compare/v0.1.0...v0.1.1) (2026-05-20)
+
+
+### Features
+
+* **ci:** add release-please + PyPI publish workflow ([#1](https://github.com/nominal-io/rsvisa-rs/issues/1)) ([0596b31](https://github.com/nominal-io/rsvisa-rs/commit/0596b31c179b464781e55c0420a441a7918bf893))

pyvisa_rs-0.1.1/CLAUDE.md

@@ -0,0 +1,85 @@
+# rsvisa-rs
+
+A Rust port of pyvisa-py's pure-Python VISA backend, plus PyO3 bindings
+(`pyvisa-rs`) that let PyVISA load the Rust implementation as the `@rs`
+backend. The Rust crate mirrors pyvisa-py module-for-module so a user can
+swap backends without behaviour changing.
+
+## Layout
+
+- `src/` — the `rsvisa-rs` crate. Module names track pyvisa-py:
+  `serial.rs` ↔ `pyvisa_py/serial.py`, `tcpip.rs` ↔ `tcpip.py`,
+  `usb.rs` ↔ `usb.py`, `vxi11.rs` ↔ `protocols/vxi11.py`, etc.
+  `session.rs` is the `ResourceManager` dispatcher (mirrors pyvisa-py's
+  `highlevel.PyVisaLibrary` + `sessions.Session`).
+- `pyvisa-rs/` — PyO3 bindings. `src/lib.rs` exposes a `#[pyclass]`
+  wrapping `ResourceManager`; `python/pyvisa_rs/__init__.py` is the
+  `VisaLibraryBase` subclass that PyVISA discovers via `pyvisa_*` package
+  scanning. `examples/discovery.py` runs both backends side-by-side.
+- `pyvisa-py/` — the **vendored upstream Python implementation**. This is
+  the source of truth for behaviour; consult it before adding new features
+  or fixing bugs.
+- `xtask/` — `cargo xtask visa-discovery` runs discovery against both
+  backends and diffs the results. Used by `tests/pyvisa_py_parity.rs`.
+- `tests/` — integration tests, including pyvisa-py parity.
+
+## The parity rule
+
+**rsvisa-rs aims for 100% behavioural parity with pyvisa-py.** When you
+find a divergence, the fix is to make rsvisa-rs match pyvisa-py — never
+to special-case the reported symptom.
+
+Before writing a fix:
+
+1. Open the corresponding file in `pyvisa-py/pyvisa_py/`.
+2. Read the pyvisa-py implementation and understand its full semantics,
+   not just the case the user reported.
+3. Replicate those semantics in Rust. If pyvisa-py uses a regex,
+   pyserial behaviour, or a libusb quirk, the Rust port should produce
+   the same observable result for **all** inputs, not just the failing
+   one.
+4. Add a regression test that captures the broader semantic, not just
+   the specific bug.
+
+When pyvisa-py itself is inconsistent or buggy, prefer matching it
+anyway and flag the divergence to the user — don't silently "improve"
+on the reference.
+
+## Commands
+
+- `cargo xtask visa-discovery [QUERY]` — diff discovery between
+  rsvisa-rs and the vendored pyvisa-py. `--check` exits non-zero on
+  divergence.
+- From `pyvisa-rs/`:
+  `uv run --with pyvisa --with pyserial --with pyusb --with libusb-package --with zeroconf --with pyvisa-py examples/discovery.py [QUERY]`
+  — same diff, but through the PyO3 bindings (the `@rs` backend) vs
+  pyvisa-py both running inside PyVISA. Pass `--reinstall-package pyvisa-rs`
+  after Rust source changes; uv's wheel cache does not invalidate on
+  Rust source edits.
+- `cd pyvisa-rs && maturin develop` — fast editable iteration on the
+  PyO3 bindings inside an activated venv.
+
+## Style
+
+- No comments unless they explain a non-obvious WHY (a pyvisa-py quirk
+  being mirrored, an unintuitive VISA spec rule, a workaround for a
+  specific platform). Don't restate what the code does.
+- Don't add backwards-compatibility shims or speculative abstractions.
+- The Rust API uses snake_case names that match pyvisa-py's Python
+  method names (`open_default_resource_manager`, `list_resources`,
+  `read_stb`, `gpib_command`, …). Don't rename them.
+
+## Releases
+
+PR titles must follow [Conventional Commits](https://www.conventionalcommits.org/)
+(`feat:`, `fix:`, `feat!:` for breaking, `chore:`, `docs:`, …) — this is
+enforced by the `lint pr title` workflow and drives release-please's
+semver bumps.
+
+## Dependency notes
+
+- `rusb` (libusb) needs `libusb-1.0-0-dev` on Linux. Windows is not
+  currently in CI because `libusb1-sys` doesn't vendor by default.
+- `serialport` needs `libudev-dev` on Linux.
+- The PyO3 binding is built with `abi3-py310`, so a single wheel covers
+  Python 3.10+.