Skip to content

MRD Viz: one-step researcher install (D1 + D3 + release) - #91

Open
ShiyunXu wants to merge 101 commits into
ismrmrd:mainfrom
ShiyunXu:feat/mrd-viz-researcher-release
Open

MRD Viz: one-step researcher install (D1 + D3 + release)#91
ShiyunXu wants to merge 101 commits into
ismrmrd:mainfrom
ShiyunXu:feat/mrd-viz-researcher-release

Conversation

@ShiyunXu

@ShiyunXu ShiyunXu commented Aug 25, 2026

Copy link
Copy Markdown

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)

  1. Open https://github.com/ismrmrd/mrd/releases/latest
  2. Download the VSIX for the platform (linux-x64, win32-x64, darwin-arm64).
  3. VS Code → Extensions: Install from VSIX...
  4. Open a .mrd file.

On those platforms the VSIX carries the extension and a standalone backend binary: no repo clone, dev container, Python, PyPI, Node, or backend configuration.

⚠️ The stable link does not serve MRD Viz yet

releases/latest currently resolves to core MRD v2.2.1, whose assets are mrd-2.2.1.mltbx, mrd-cmake-src-2.2.1.tar.gz, and sha256-checksums.txt. There is no mrd-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.1

Installable right now, without waiting

The release matrix already ran green on the current carter-mrd-viz head (7ac9ffd) and its artifacts are live: MRD Viz Release run #24vsix-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

  • D1 deterministic two-tier backend resolution + guided recovery
  • D3 PyInstaller one-dir backend bundled into platform VSIXs
  • release matrix for Linux x64, Windows x64, Apple Silicon
  • D3 artifact verifier and manifest contract (target, backend version, size, SHA-256)
  • GitHub Release publishing and Marketplace-ready artifact reuse
  • before/after functionality table and release runbook

Before / after

Checkpoint User flow Prerequisites
PR #78 Clone → reopen in container → just container-setup → open .mrd Git, Docker, VS Code Dev Containers
D1 without D3 Install VSIX → Set Up Backend builds a venv → open .mrd Python 3.12 + network
This PR: D1 + D3 + release Download platform VSIX → install → open .mrd VS Code only

Known gaps

  • Intel macOS (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.
  • Binaries are unsigned, so first launch can hit SmartScreen/Gatekeeper.
  • Marketplace publishing stays blocked on the ismrmrd publisher and the VSCE_PAT secret (see MARKETPLACE_RELEASE_TODO.md); those items are still marked (Owner: Carter) and need a new owner.
  • The bundled-backend smoke test against a real CI artifact is still unchecked in that TODO — worth doing with a run Bump extractions/setup-just from 2.0.0 to 3.0.0 #24 artifact before tagging.

Validation

Release 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.

ccapetz and others added 30 commits June 17, 2026 15:05
… 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.
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>
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
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
ccapetz and others added 23 commits August 4, 2026 16:09
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>
@ShiyunXu ShiyunXu closed this Aug 25, 2026
@ShiyunXu ShiyunXu changed the title MRD Viz: promote researcher-ready D1, D3, and release MRD Viz: one-step researcher install (D1 + D3 + release) Aug 25, 2026
@ShiyunXu ShiyunXu reopened this Aug 25, 2026
@ShiyunXu

Copy link
Copy Markdown
Author

Verified the D3 artifact end-to-end — one real gap found

Downloaded vsix-linux-x64 from run #24 and confirmed the VSIX is well-formed: extension/package.json, extension/out/extension.js, and the bundled extension/media/backend/mrd-viz (5.1 MB) are all present. D3 packaging works.

However, the bundled Linux backend does not run on glibc < 2.38:

[PYI-2841:ERROR] Failed to load Python shared library '.../_internal/libpython3.12.so.1.0':
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found

The binary is built on ubuntu-24.04 (glibc 2.39) and objdump confirms it requires GLIBC_2.38. Any older host fails — reproduced here on Debian 12 / glibc 2.36. That covers Ubuntu 22.04 LTS, Debian 12, and RHEL 8/9, a large share of research Linux machines.

The failure is at least diagnosed gracefully: describeProbeFailure in backendResolver.ts surfaces the linker error, and the resolver falls back to the D1 guided-setup path, so those users get a working (Python 3.12 + network) route rather than a dead end.

Windows and macOS arm64 are unaffected — different runtimes, no glibc coupling.

Options, none of which need to block this PR:

  1. Build the Linux leg on ubuntu-22.04 to lower the floor to glibc 2.35.
  2. Build in a manylinux container for a much older floor.
  3. Ship as-is and document the Linux requirement as glibc 2.38+ / Ubuntu 24.04+, otherwise use Set Up Backend.

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.

@ShiyunXu

Copy link
Copy Markdown
Author

Installing today from carter-mrd-viz (no release needed)

The mrd-viz-v* tag has never been cut, so releases/latest still resolves to core MRD v2.2.1 and the "stable link" in the docs 404s. Until someone with push access tags a release, install from the CI build artifacts instead. These are the same VSIXs the release job would upload.

Flow

  1. Sign in to GitHub (must have read access to ismrmrd/mrd — these are not anonymous links).
  2. Open the green MRD Viz Release run for the current carter-mrd-viz head (7ac9ffd):
    https://github.com/ismrmrd/mrd/actions/runs/31837361253
  3. Scroll to Artifacts and download the one for your platform:
    • vsix-win32-x64 (27.8 MB)
    • vsix-darwin-arm64 (27.7 MB)
    • vsix-linux-x64 (58.6 MB)
  4. Unzip it. You get mrd-viz-<target>-0.0.1.vsix.
  5. Install:
    • VS Code → Extensions menu → Install from VSIX…, or
    • code --install-extension mrd-viz-<target>-0.0.1.vsix
  6. Open any .mrd file. The bundled backend is picked up automatically — no Python, no pip, no venv, no settings.

Artifacts expire 2026-11-12. After that the run must be re-run, or a tag cut.

Platform status

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/mrdworkflow_dispatch returns 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants