lvpm 0.2.1

Bug-fix release. If you use lvpm with any LabVIEW older than 2026, you want
this one — on 0.2.0 and earlier, relinking failed on every package there.

Fixed: every package failed to relink on LabVIEW 2025 (error 122)

Installing any package into a LabVIEW older than 2026 failed at the first
VI Server method call:

...\vi.lib\Wiresmith Technology\G CLI ... FAILED
    invoking Ctrl Val.Set on 0x14d00017: VI Server returned error 122

Error 122 is "the resource you are attempting to open was created in a more
recent version of LabVIEW and is incompatible with this version". Because it
names a resource, it reads like a broken or too-new VI. It was the wire format.

Every flattened value lvpm sent carried a LabVIEW 2026 version stamp. A server
unflattens data stamped at or below its own version and rejects anything above
it. Relinking a folder begins by setting the folder control, so the stamp failed
every package on an older LabVIEW while working perfectly on 2026.

Flattened data is now stamped LabVIEW 2020, the oldest release lvpm supports and
the version the bundled relink VI is saved for.

This is not the handshake. That stamp is tolerated in both directions — a 2025
server accepts a client claiming 2026 — which is why the connection came up
cleanly and only the first method call failed.

Verified on a live LabVIEW 2025 (64-bit) v25.3: the call that returned 122 now
succeeds and the VI runs.

Fixed: the install script

• The final line ran lvpm --version with a trailing &. On PowerShell 7 that
  is the background operator, so the version never printed and the run ended on
  the bare word installed. On Windows PowerShell 5.1 the script did not parse
  at all, against its own #Requires -Version 5.1. It now prints
  lvpm 0.2.1 installed.
• .\install.ps1 with no arguments always failed with no release found.
  Invoke-RestMethod returns a JSON array as one object, so the release filter
  tested the whole array instead of each release. Pinning a tag with -Version
  was unaffected, which is what made it look like a permissions problem.
• The README now says to cd somewhere writable first. An elevated PowerShell
  starts in system32, where the download cannot be written, and the resulting
  access-denied error looks like a network failure.

Install

cd $env:TEMP
irm https://raw.githubusercontent.com/Flydroid/lvpm/main/scripts/install.ps1 -OutFile install.ps1
.\install.ps1

If lvpm still reports an old version afterwards, check for a copy left by
cargo install in %USERPROFILE%\.cargo\bin, which comes earlier on PATH
than the install directory and will shadow it.

Verifying the download

The zip's SHA-256 is recorded by GitHub as the asset digest and shipped in
SHA256SUMS. The install script checks both. By hand:

Get-FileHash -Algorithm SHA256 .\lvpm-0.2.1-windows-x64.zip

90d20ec6c03b4a45a52973cc5adfee31fc14f8c55b8ab72962384243adfa488f

Known limitations

• LabVIEW must be running for lvpm to relink; lvpm starts it when it is not,
  except in a headless run. Note that LabVIEW accepts a TCP connection on the
  VI Server port several seconds before it will answer a handshake, so a
  readiness check based on the port alone reports ready too early.
• In LabVIEW 2026 the relink VI is initially blocked because it comes from an
  untrusted source.
• Hook VIs' own error out is not read back. No mass compile. Windows only.

Not affiliated with JKI or NI.

lvpm 0.2.0

Second release of lvpm, an open-source package manager for LabVIEW packages.

What's in the box

lvpm.exe and the two licences. Unzip anywhere and put the folder on your
PATH — or let the install script do it:

irm https://raw.githubusercontent.com/Flydroid/lvpm/main/scripts/install.ps1 -OutFile install.ps1
.\install.ps1

The relink VI is no longer a companion file: it is embedded in the
executable and written out to a temporary path when it is needed, so the
binary you run no longer depends on a source checkout beside it. It is
still saved for LabVIEW 2020, so any LabVIEW from 2020 on can load it.

New since 0.1.0-alpha.1

• Per-project dependencies (venvs). lvpm venv create makes a .project
  venv mounted through LVAddons, so a project's packages live beside the
  project instead of in the LabVIEW installation. lvpm launch starts a
  LabVIEW that sees it.
• lvpm.toml, lvpm's own manifest, with a [sources] table and version
  constraints. Any command run at or below it picks it up, and lvpm install
  with no arguments installs the whole list as one plan with one relink pass.
• Headless LabVIEW for containers and CI. Handshake-based readiness
  instead of a fixed wait, and relink and hooks are off by default in a
  headless run rather than silently starting a LabVIEW. --relink and
  --hooks turn them back on.
• Upgrades. Installing over an installed package upgrades it; a
  downgrade is refused unless you pass --allow-downgrade.
• lvpm uninstall --all removes every package in the target.
• Palette and menu refresh after install, uninstall and hooks, and
  lvpm refresh to do it on its own.
• lvpm start starts the selected LabVIEW and waits until its VI Server
  answers; lvpm run-hooks reruns a PostInstall hook that failed during
  install.
• app-probe joins the vi-probe / vi-run / vi-save VI Server
  primitives, and all of them talk to the venv's LabVIEW when a venv is in
  effect.
• An install script that verifies the download's SHA-256 before it
  extracts anything, and a contributor setup guide.

Fixes

• A number inside a package name is no longer read as the package version.
• Files that Replace Mode = If Newer left alone are now recorded in the
  install manifest, so uninstall accounts for them.
• The relink VI is bundled with the application rather than looked up on disk.

Verifying the download

The zip's SHA-256 is recorded by GitHub as the asset digest and shipped in
SHA256SUMS. The install script checks both. By hand:

Get-FileHash -Algorithm SHA256 .\lvpm-0.2.0-windows-x64.zip

07c3a9d09b233657cdadd1320ae64f5272925e16effc0858c17af2a2ad96050b

Known limitations

• LabVIEW must be running for lvpm to relink; lvpm starts it when it is not,
  except in a headless run.
• In LabVIEW 2026 the relink VI is initially blocked because it comes from an
  untrusted source.
• Hook VIs' own error out is not read back. No mass compile. Windows only;
  Linux target detection exists but is untested.

See the README for the full list. Not affiliated with JKI or NI.

lvpm 0.1.0-alpha.1

First alpha of lvpm, an open-source package manager for LabVIEW packages.

What's in the box

lvpm.exe and tools\Relink Package.vi — unzip anywhere, keep them side by side, optionally add the folder to PATH. The relink VI is saved for LabVIEW 2020, so any LabVIEW from 2020 on can load it.

What works

• lvpm install <name>[@version] — resolve transitively from the public repositories (or a local folder of .vip files via --repo), verify MD5, unpack into a LabVIEW installation or a --prefix sandbox
• lvpm install --manifest <vipm.toml> — install a project's whole dependency list as one plan with one relink pass
• relinking through VI Server, with cross-package folder dedup and retry handling
• PreInstall / PostInstall / PreUninstall / PostUninstall hook VIs extracted and run at their proper moments, handed the action-info variant (Quiet Mode = TRUE) so they run headless
• lvpm uninstall, list, search, targets, relink --all, --dry-run
• VI Server primitives: vi-probe, vi-run, vi-save

Relinking and hooks need a running LabVIEW with VI Server (TCP) enabled; everything else runs without any LabVIEW process.

Verified end to end: a 46-dependency project manifest resolved to 48 packages / 8766 files, installed, relinked and its 15 post-install hooks run from a single command.

Known limitations

• LabVIEW needs to be running for lvpm to run the relinking
• The paletts and tools are not updated automatically
• In LV2026 the "Relink Package.vi" is broken initially because it comes from an untrusted source

See the README — notably: hook VIs' own error out is not read back, Replace Mode = If Newer only writes when the file is absent, no mass compile, Windows only.

Not affiliated with JKI or NI.