Installation

Vyges is distributed as prebuilt binaries (the source is private). You need neither Rust nor a package manager to install it.

Every release bundles six binaries — vyges, vyges-catalog, vyges-mcp, vyges-metadata, vyges-model and vyges-pdk-store — and installs them into ~/.vyges/bin. They move as a set: an install or upgrade replaces all six, so the components never drift apart.

Homebrew (macOS / Linux)

brew install vyges/tap/vyges

This installs all six binaries in one shot.

curl installer (macOS / Linux)

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh

The installer places the binaries in ~/.vyges/bin and adds that directory to your PATH by appending a line to your shell startup files (~/.profile, ~/.bashrc, ~/.zshrc, and fish’s conf.d).

To leave your shell configuration untouched, set VYGES_NO_MODIFY_PATH=1:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | VYGES_NO_MODIFY_PATH=1 sh

Worth doing if you build EDA tools from source and do not want an installed vyges-<engine> shadowing your own build. You then put the directory on PATH yourself, per shell or per command:

export PATH="$HOME/.vyges/bin:$PATH"

The Vyges Loom engines (on demand)

The sign-off engines — the Vyges Loom suite — are not bundled with the CLI. Fetch the whole suite when you want it, then invoke any engine through vyges:

vyges install loom        # downloads the Loom engines into ~/.vyges/bin
vyges loom sta-si demo    # run any engine as: vyges loom <engine> ...
vyges opendb info --input design.odb   # including the design database itself

Each engine is also a standalone vyges-<engine> binary on your PATH (e.g. vyges-sta-si), which is what vyges loom <engine> dispatches to and what flow authors integrate against directly.

Verify

vyges --version
vyges modules        # shows which Vyges modules are installed (incl. the loom suite)

vyges modules also reports each engine’s contract — the descriptor version it speaks. 1.1 is current. An engine showing pre predates the convention: it still runs, and reinstalling it picks up a build that declares one.

Upgrading

vyges update

One command on every platform. It checks for a newer release, replaces all six binaries together, and reports what moved; if you are already current it says so and does nothing. It leaves your shell startup files alone.

Available from 0.1.26. Earlier builds do not ship the updater, so vyges update there reports unknown command 'update'. Upgrade once with the installer below and vyges update works from then on.

Re-running the installer also works, and is the way to upgrade a pre-0.1.26 install:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh

If you installed with Homebrew, use Homebrew instead — writing into a brew-managed prefix by hand gets undone by its next upgrade:

brew upgrade vyges/tap/vyges

The Loom engines upgrade separately, since they release from their own repos:

vyges install loom        # re-run to refresh the suite

Installing a specific version

Every release keeps its own installer, so a version is pinned by asking for its tag instead of latest — which is what CI should do, and what to reach for if a new release regresses something you depend on:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/vyges-tools/cli/releases/download/v0.1.24/vyges-installer.sh | sh

Published releases are never deleted or rewritten, so a pinned version stays available.

Uninstalling

The installer only adds files under ~/.vyges and a PATH line to your shell profile:

rm -rf ~/.vyges/bin        # the CLI, its components, and any installed engines
rm -rf ~/.vyges            # also removes caches, PDK descriptors and catalog config

Then delete the ~/.vyges/bin line from whichever profile picked it up (~/.profile, ~/.zshrc, ~/.bashrc, or ~/.config/fish/conf.d/). Homebrew installs uninstall with brew uninstall vyges.

Supported platforms

• macOS (Apple Silicon)
• Linux (x86-64 and arm64)

Windows is not supported. The suite installs opendb, which builds on OpenROAD’s libodb — and upstream odb has no Windows support at all: no _WIN32 handling in its CMake, and POSIX-only headers across more than a dozen files. Supporting Windows would mean forking and maintaining a port of upstream C++ against a moving target, and a CLI that cannot install half the suite is worse than no CLI. On Windows, use WSL2, where the Linux build runs unchanged.