cdlvsm

Package manager and dispatcher CLI for codelovesme's first-party command-line tools.

cdlvsm installs a tool, keeps it under a versioned directory, and then transparently runs it for you:

cdlvsm install code
cdlvsm code run hello.code      # runs the installed `code` binary

cdlvsm <package> <args...> execs the installed binary directly, forwarding argv and inheriting stdin/stdout/stderr, exit code, and signals — so cdlvsm code ... behaves exactly like running code ... would.

Install

Linux x86_64 only, for now.

curl -sSf https://raw.githubusercontent.com/codelovesme/cdlvsm/main/install.sh | sh

Installs the cdlvsm binary to ~/.local/bin (override with PREFIX=...; pin a version with CDLVSM_CLI_VERSION=v0.x.y). Add ~/.local/bin to your PATH if it isn't already.

Usage

cdlvsm install <package> [--runtime] [--link] [--no-desktop]
               [--with <feature>] [--no-service] [--dry-run]
cdlvsm uninstall <package>...
cdlvsm autoremove                remove what was installed only for removed packages
cdlvsm upgrade [package]
cdlvsm update
cdlvsm list
cdlvsm service <package> <start|stop|restart|status|install-unit|uninstall-unit>
cdlvsm <package> <args...>       run an installed package's binary

Packages

Package	What it is
code	the Code language toolchain
euglena	the euglena app CLI (scaffold/run/build Euglena apps)
ide	the codelovesme IDE, in the terminal — cdlvsm ide [folder]
mike	Mike, your Euglena assistant on Linux — cdlvsm mike
mike-service	Mike's shared local service on its own, e.g. on a headless server (no release published yet)

Dependencies

Packages declare what they need — other packages with version constraints, optional features, operating-system capabilities, a per-user service — and cdlvsm resolves that whole graph before changing anything: it reuses a compatible installed package, installs what is missing, upgrades a shared package only when everything using it accepts the new version, and otherwise refuses and names what is in the way. Archives are checked against their published sha256, staged, and activated in dependency order with the requested package last, under a lock so concurrent installs take turns. uninstall keeps what another package still needs, and autoremove removes what was only installed for packages that are gone. The format, the policies and their limits are in docs/package-dependencies.md.

euglena runs apps through the code interpreter, so cdlvsm install euglena also installs code (SDK tier, no --link) if it isn't already installed — a declared dependency — and points euglena at cdlvsm's code shim — no separate install code or euglena code set step needed. That wiring keeps working across cdlvsm upgrade code too, since the shim always tracks whichever version is current. To use a different code build instead, run euglena code set <path> yourself afterwards.

ide is a bundle rather than a lone binary — a launcher, the app's program and the modules it links, run by the code interpreter — so cdlvsm install ide also installs code if it isn't there. Every package's whole release directory is installed, not only its binary.

cdlvsm install mike installs the current Mike release (0.4.x), which brings in Code 2.12.1 or newer, upgrading an older managed Code install before adding the app. On supported Debian and Ubuntu desktops it also installs WebKitGTK, Python GI, and the document portal through apt when they are missing. The release includes its own pinned Euglena modules and connects directly to the public HTTPS service. Sign in through your browser when Mike asks to connect; there is no checkout or tunnel to set up. The earlier mike-desktop package name remains supported for existing users.

From Mike 0.5 the Desktop window and Mike's shared local service are separate packages: Desktop requires mike-service, which cdlvsm install mike installs or reuses, and a headless server installs mike-service alone (Python 3 and Code, no display packages). The service needs a Code from 2.12.1 to before 2.15.0; with a newer Code active, cdlvsm installs a compatible one beside it rather than replacing it. Installing registers the service's systemd user unit but neither starts it nor pairs anything. See docs/package-dependencies.md.

Apps in the desktop's menu

A package that is an app — ide, console — goes in the desktop's own applications menu when it is installed, so it is found in GNOME's search, KDE's menu, Spotlight. On Linux (any desktop that follows XDG: GNOME, KDE, XFCE, Cinnamon…) that is a desktop entry, ~/.local/share/applications/codelovesme-<pkg>.desktop; on macOS an app bundle in ~/Applications. A terminal app like ide opens in the codelovesme console when that is installed (any installed app whose app.info says runs-programs=-e — cdlvsm-console -e …), and otherwise is marked as a terminal app, so the desktop opens its own terminal for it. Installing or removing such a terminal rewrites the terminal apps' entries to match. The entry starts the app through its cdlvsm-<pkg> shim, so it follows upgrades; uninstall takes it away (only an entry cdlvsm wrote). --no-desktop leaves it out, and is remembered.

An app says what it is called in an app.info in its release (name=, comment=, terminal=true, icon=, categories=, keywords=, runs-programs=); cdlvsm has defaults for its own. Windows (a Start Menu shortcut) follows when cdlvsm runs there.

code install flags

• --runtime — install the smaller, LLVM-free interpreter-only tier instead of the default SDK (which also has the native/wasm compiler). Tiers only exist for releases that ship separate per-tier builds (code did through v0.4.1); from v0.5.0 on there is a single build, and cdlvsm installs it with a note regardless of the tier flag.
• --link — additionally create a bare code command in $PREFIX/bin. By default cdlvsm install code only creates a cdlvsm-code shim, not a bare code, because code collides with VS Code's own code CLI on Linux. Opt into the bare name only if you know you want it.

Environment

• PREFIX — install root (default $HOME/.local). Packages live under $PREFIX/share/cdlvsm/packages/<pkg>/<version>/; shims under $PREFIX/bin.
• CDLVSM_CODE_VERSION / CDLVSM_EUGLENA_VERSION — pin a package's version instead of fetching the latest release (e.g. v0.3.0).
• CDLVSM_CLI_VERSION — pin which cdlvsm build to fetch, for both install.sh and cdlvsm update.
• CDLVSM_LOCAL_RELEASES — install from a local directory laid out like GitHub releases (staged, unpublished packages; isolated tests).
• CDLVSM_NO_SYSTEM_INSTALL=1 — report missing operating-system packages instead of installing them.

Updating

cdlvsm upgrade updates packages to their latest (or version-pin) release:

cdlvsm upgrade code        # update one package
cdlvsm upgrade             # update every installed package

upgrade reuses the settings the package was installed with (recorded in $PREFIX/share/cdlvsm/packages/<pkg>/.cdlvsm) — a code --runtime --link install stays a --runtime install with its bare code link, and enabled --with features stay enabled. Upgrading every package goes dependents first, so a client's new release brings the shared package it needs. If a package is already at the latest (or pinned) version, it's reported as "already up to date" and skipped. upgrade takes no flags; to change tier or --link, re-run cdlvsm install <package> with the new flags.

cdlvsm update is the same idea for cdlvsm itself — distinct from upgrade, which only touches installed packages. It downloads the latest (or CDLVSM_CLI_VERSION-pinned) release and replaces the running binary in place; no shell restart needed, the new version takes effect immediately.

Uninstall safety

cdlvsm uninstall <pkg> removes a shim in $PREFIX/bin only if it's a symlink cdlvsm itself created (one that resolves back into the package's own directory). A same-named binary you installed some other way — e.g. VS Code's real code — is never touched, and install --link refuses rather than replace it.

uninstall refuses while another installed package still needs the one being removed, and says which; name them together to remove them together. A service package's unit is removed with it; its configuration and state are not.

Building from source

cargo build --release       # ./target/release/cdlvsm
cargo test                  # offline tests
CDLVSM_NETWORK_TESTS=1 cargo test   # also runs the real install-from-GitHub test

No LLVM or other system dependencies — cdlvsm shells out to curl/tar/ sha256sum at runtime (all required on PATH) rather than embedding an HTTP/archive/hash stack. See docs/package-dependencies.md for the gated network, staged-Mike and systemd exercises.

License

GPL-3.0-or-later — see LICENSE.