MRD Viz: one-step researcher install (D1 + D3 + release) - #91
Conversation
… backward compatibility for unknown schema versions and what error views will be supported
First official technical design outline for the mrd-viz extension. Small questions regarding error handling and backwards compatibility remain open and will be answered with further real-world testing.
Add MRD Viz scaffold
Escape '<' before embedding to avoid injection/unexpected behavior for JSON payload handling Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Removed unused import of Counter from collections.
…ly break for extract_image command, clarified schema_version html_harness definitions, unified backend default values, added instructions for generating mrd test files
…ds, added test case for this functionality
Add MRD Viz backend CLI Test through `OFFICIAL_EXT_DEV_RUNBOOK.md` which has powershell and linux bash commands, guides users through generating test mrd files Test suite also added and will be expanded upon, will run on any PRs targetting carter-mrd-viz
Replace the 5-candidate search with a pure planBackendCandidates(): a configured override is the ONLY candidate (no silent fallback), otherwise the bundled binary, with the repo .venv tried first only in the F5 Development host. Adds BackendKind and getConfiguredBackendPath (backendPath, then legacy explicit pythonPath). Drops managed-venv and PATH candidates.
selectInterpreter and the guided setup now write the machine-scoped mrdViz.backendPath (no more workspace scope-clearing needed), so the managed venv becomes a first-class override rather than an implicit resolver candidate. Config invalidation watches backendPath and pythonPath.
Lead with the relevant explanation and primary action: a broken mrdViz.backendPath override vs. a bundled backend that won't run on this platform. Update references to backendPath.
Uses mrdViz.backendPath (applied as a container remote setting) instead of the deprecated pythonPath, so the container interpreter can't leak to the host.
…implemented Unit-test planBackendCandidates (override no-fallback, dev vs prod order, binary classification, empty) and the tailored override page. Update BACKEND_INSTALL_MODES (target -> implemented) and DEVCONTAINER (machine-scoped backendPath, leak now structurally prevented).
…et/toast/doc - Override candidate/logs and the backend-missing page now name the setting the value came from (backendPath vs legacy pythonPath) instead of always backendPath. - Setup snippet installs editable from a checkout (mrd-viz is not on PyPI). - Interpreter-selection toast is setting-neutral (path may be a binary). - Reconcile BACKEND_INSTALL_MODES intro (pre-refactor, not current). - Tests for the legacy-setting labeling.
- centralize magic timeouts/buffers/names in backendConstants.ts - add runProcess() execFile wrapper; use it in resolver, runner, provisioning - use PYPI package name mrd-viz and add --disable-pip-version-check --no-input to pip; TODO(publish-pypi) - drop unused getConfiguredBackendPath export - refresh stale mrdViz.pythonPath -> mrdViz.backendPath references in docs and postCreate - update backend-missing test fixture to realistic post-refactor sources
The un-scoped legacy setting could leak across machines (e.g. a Linux path synced into Windows User settings) and, treated as an exclusive override, suppressed the bundled binary and forced the backend-not-found page. Only the machine-scoped mrdViz.backendPath is honored now. - resolver reads only mrdViz.backendPath; remove legacy inspect() branch and settingKey plumbing - remove deprecated mrdViz.pythonPath declaration and config-change watch - simplify backend-missing intro to name mrdViz.backendPath; drop two legacy tests
…etworks Corporate networks block public PyPI (files.pythonhosted.org SSL handshake failure) and public npm. Add select-pkg-index.sh, a candidate-ladder helper sourced by postCreate and container-setup that probes the Microsoft-internal mirror first and falls back to the public registry, exporting PIP_INDEX_URL/npm_config_registry. Candidate lists live in devcontainer.json remoteEnv (discoverable, external devs still work). Prints the exact export line on total failure; documented in DEVCONTAINER.md.
- resolveBackend now returns an explicit 'no backend available' failure when there are no candidates (no override + no bundled binary), instead of an empty attempt list the webview can't explain (yuliadub). - Extract the hardcoded 'mrd-viz' binary name to BACKEND_BINARY_NAME so a rename touches one place (yuliadub). - setUpBackend confirms a Reinstall when a managed backend already exists, rather than silently rebuilding it (yuliadub).
…-core mrd-viz: deterministic two-tier backend resolution
MRD Viz: Marketplace release prep + publish job
- pull_request/push filters matched the PR base branch (carter-mrd-viz), so neither workflow ran for PRs into main; target main instead - pin @vscode/vsce to an exact version in the package/publish steps - pin softprops/action-gh-release to a commit SHA (was mutable v2 tag) Addresses review comments on PR ismrmrd#87.
- reject --slice AXIS above a small cap so a huge axis returns a diagnostic instead of attempting an enormous dense-tuple allocation - guard the webview mosaic against a non-array thumbnails value so a malformed backend payload cannot throw and blank the editor Addresses review comments on PR ismrmrd#87.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Verified the D3 artifact end-to-end — one real gap foundDownloaded However, the bundled Linux backend does not run on glibc < 2.38: The binary is built on The failure is at least diagnosed gracefully: Windows and macOS arm64 are unaffected — different runtimes, no glibc coupling. Options, none of which need to block this PR:
Option 1 is a one-line matrix change and covers most of the gap. Worth doing before tagging, since the release is the artifact researchers actually install. |
Installing today from
|
| Platform | Works out of the box | Notes |
|---|---|---|
| Windows x64 | Yes | Clean |
| macOS arm64 | Yes | Clean; may need Gatekeeper approval (unsigned) |
| macOS x64 (Intel) | No artifact | Deliberately dropped from the matrix — Intel runners queue indefinitely |
| Linux x64 | Only on glibc ≥ 2.38 | See below |
Linux caveat: the bundled binary is built on ubuntu-24.04 (glibc 2.39) and links GLIBC_2.38. On Ubuntu 22.04 LTS, Debian 12, and RHEL 8/9 it fails to load and the extension falls back to the D1 Set Up Backend guided path (which needs Python 3.12 + network). Fix is a one-line matrix change to ubuntu-22.04, ideally before any real tag.
Why there is no new dry run in this thread
I could not trigger one:
ismrmrd/mrd—workflow_dispatchreturns 403, requires admin.- Fork
ShiyunXu/mrd— workflows are not registered; forks need the one-time "enable workflows" confirmation in the Actions UI, which has no API equivalent.
Run #24 above is already a complete, green dry run of the exact commit at the head of this branch, so it is equivalent to what a fresh dispatch would produce.
Scope
One approval, one researcher UX. D1, D3, and release are intentionally not separated. The standalone-backend implementation ships here; there is no follow-on D3 PR. #92, which re-split D3 into its own change, has been closed in favour of this PR.
Researcher UX (after this merges and a tag is pushed)
linux-x64,win32-x64,darwin-arm64)..mrdfile.On those platforms the VSIX carries the extension and a standalone backend binary: no repo clone, dev container, Python, PyPI, Node, or backend configuration.
releases/latestcurrently resolves to core MRDv2.2.1, whose assets aremrd-2.2.1.mltbx,mrd-cmake-src-2.2.1.tar.gz, andsha256-checksums.txt. There is nomrd-viz-*tag on this repo, so there is nothing to install from that URL today.The link becomes the install page only after this merges and someone with push access tags a release:
git tag mrd-viz-v0.0.1 && git push origin mrd-viz-v0.0.1Installable right now, without waiting
The release matrix already ran green on the current
carter-mrd-vizhead (7ac9ffd) and its artifacts are live: MRD Viz Release run #24 —vsix-linux-x64,vsix-win32-x64,vsix-darwin-arm64, all unexpired until 2026-11-12.That run is the D3 proof: it built the PyInstaller backend per platform, probed each one with
--version, and packaged a platform-targeted VSIX. Download the artifact for your platform, unzip, and install the.vsix— that is the zero-prerequisite experience, available before any tag exists.Included
Before / after
just container-setup→ open.mrd.mrd.mrdKnown gaps
darwin-x64) is not covered. The runner pool was winding down and the leg was dropped; those users fall back to the D1 guided-setup path.ismrmrdpublisher and theVSCE_PATsecret (seeMARKETPLACE_RELEASE_TODO.md); those items are still marked (Owner: Carter) and need a new owner.Validation
npm auditcleanRelease action after merge
Push
mrd-viz-v0.0.1. The workflow builds, probes, packages, and publishes the platform VSIXs, and the stable URL then becomes the researcher handoff link.