dsh-plugin-local-infer 0.1.3 → 0.1.4

package/packages/providers/lib/engines/ninfer/ninferLinux.js

@@ -0,0 +1,37 @@
+/**
+ * The NInfer shared Linux build profile. Every Linux distro (Arch, Debian,
+ * Fedora) builds NInfer through this one route: cmake with the Ninja generator
+ * into the `build` directory, which is where the `ninfer-serve` binary lands.
+ * The distro profiles reuse this profile, so a distro carries no build steps of
+ * its own.
+ * @module dsh-plugin-local-infer/providers/engines/ninfer/ninferLinux
+ */
+import { SYSTEM_DEPS } from "../../systemDeps.js";
+export const NINFER_LINUX = {
+    buildSteps: [
+        'cmake -S {dir} -B {dir}/build -G Ninja -DCMAKE_BUILD_TYPE=Release && cmake --build {dir}/build -j',
+    ],
+    buildDir: 'build',
+    binary: 'ninfer-serve',
+    // The Linux local build needs the compile toolchain (cmake, ninja), the
+    // ffmpeg and curl dev libraries (pkg-config, ffmpeg, curl), the CUDA
+    // toolkit, and the hf CLI to download the model.
+    deps: [
+        SYSTEM_DEPS.cmake,
+        SYSTEM_DEPS.ninja,
+        SYSTEM_DEPS.pkgConfig,
+        SYSTEM_DEPS.ffmpeg,
+        SYSTEM_DEPS.curl,
+        SYSTEM_DEPS.cudaToolkit,
+        SYSTEM_DEPS.hfCli,
+    ],
+};
+/**
+ * ninferLinuxBinary returns the NInfer engine binary name on Linux: the plain
+ * `ninfer-serve` (no .exe). The name comes from the shared Linux profile, so
+ * the spelling has one home.
+ */
+export function ninferLinuxBinary() {
+    return NINFER_LINUX.binary ?? 'ninfer-serve';
+}
+//# sourceMappingURL=ninferLinux.js.map

package/packages/providers/lib/engines/ninfer/ninferMacOS.d.ts

@@ -0,0 +1,15 @@
+/**
+ * The NInfer macOS build profile. macOS builds NInfer through the same cmake
+ * route as Linux, so this profile reuses the shared Linux build steps and
+ * build directory; the binary keeps its plain name (no .exe on macOS).
+ * @module dsh-plugin-local-infer/providers/engines/ninfer/ninferMacOS
+ */
+import type { EngineOsProfile } from '../engineOs.ts';
+export declare const NINFER_MACOS: EngineOsProfile;
+/**
+ * ninferMacOSBinary returns the NInfer engine binary name on macOS: the plain
+ * `ninfer-serve` (no .exe on macOS). The name comes from the shared Linux
+ * profile the macOS profile reuses, so the spelling has one home.
+ */
+export declare function ninferMacOSBinary(): string;
+//# sourceMappingURL=ninferMacOS.d.ts.map

package/packages/providers/lib/engines/ninfer/ninferMacOS.js

@@ -0,0 +1,17 @@
+/**
+ * The NInfer macOS build profile. macOS builds NInfer through the same cmake
+ * route as Linux, so this profile reuses the shared Linux build steps and
+ * build directory; the binary keeps its plain name (no .exe on macOS).
+ * @module dsh-plugin-local-infer/providers/engines/ninfer/ninferMacOS
+ */
+import { NINFER_LINUX } from "./ninferLinux.js";
+export const NINFER_MACOS = NINFER_LINUX;
+/**
+ * ninferMacOSBinary returns the NInfer engine binary name on macOS: the plain
+ * `ninfer-serve` (no .exe on macOS). The name comes from the shared Linux
+ * profile the macOS profile reuses, so the spelling has one home.
+ */
+export function ninferMacOSBinary() {
+    return NINFER_MACOS.binary ?? 'ninfer-serve';
+}
+//# sourceMappingURL=ninferMacOS.js.map

package/packages/providers/lib/engines/ninfer/ninferWindows.d.ts

@@ -0,0 +1,29 @@
+/**
+ * The NInfer Windows build profile. The Windows route is the ninfer-all fork's
+ * vcpkg build: the manifest pulls the dev libraries, then the engine's own
+ * build-native.bat configures and builds. The step cds into the checkout first
+ * (the {dir} placeholder), because vcpkg install and the relative script path
+ * both resolve against the checkout root.
+ *
+ * The build leaves the engine binary in the Windows build tree, not the Linux
+ * build directory: the vcpkg route writes ninfer-serve.exe into
+ * build-windows\apps\Release, so the launch step reads the binary from that
+ * directory, not from the shared Linux build directory. The launch binary is
+ * the path relative to the checkout root (the engine directory the spawn runs
+ * in), so the spawn resolves it against the default or override engine dir.
+ * @module dsh-plugin-local-infer/providers/engines/ninfer/ninferWindows
+ */
+import type { EngineOsProfile } from '../engineOs.ts';
+export declare const NINFER_WINDOWS: EngineOsProfile;
+/**
+ * ninferWindowsBinary returns the NInfer launch binary on Windows: the path
+ * relative to the checkout root (the engine directory the spawn runs in) where
+ * the vcpkg build-native route writes the Release binary,
+ * `build-windows/apps/Release/ninfer-serve.exe`. The directory and the .exe
+ * name both come from the Windows profile, so the build tree and the spelling
+ * have one home. `join` keeps the result cross-platform: the host's path module
+ * normalizes the separators, so the spawn resolves it on Windows, Linux, and
+ * macOS alike.
+ */
+export declare function ninferWindowsBinary(): string;
+//# sourceMappingURL=ninferWindows.d.ts.map

package/packages/providers/lib/engines/ninfer/ninferWindows.js

@@ -0,0 +1,59 @@
+/**
+ * The NInfer Windows build profile. The Windows route is the ninfer-all fork's
+ * vcpkg build: the manifest pulls the dev libraries, then the engine's own
+ * build-native.bat configures and builds. The step cds into the checkout first
+ * (the {dir} placeholder), because vcpkg install and the relative script path
+ * both resolve against the checkout root.
+ *
+ * The build leaves the engine binary in the Windows build tree, not the Linux
+ * build directory: the vcpkg route writes ninfer-serve.exe into
+ * build-windows\apps\Release, so the launch step reads the binary from that
+ * directory, not from the shared Linux build directory. The launch binary is
+ * the path relative to the checkout root (the engine directory the spawn runs
+ * in), so the spawn resolves it against the default or override engine dir.
+ * @module dsh-plugin-local-infer/providers/engines/ninfer/ninferWindows
+ */
+import { join } from 'node:path';
+import { SYSTEM_DEPS } from "../../systemDeps.js";
+export const NINFER_WINDOWS = {
+    buildSteps: [
+        '$env:PATH="C:\\Program Files\\Microsoft Visual Studio\\18\\Community\\VC\\vcpkg;$env:PATH"; $env:NINFER_VCPKG_ROOT="C:\\Program Files\\Microsoft Visual Studio\\18\\Community\\VC\\vcpkg"; cd {dir} && vcpkg install && .\\scripts\\build-native.bat configure && .\\scripts\\build-native.bat build && .\\scripts\\build-native.bat build',
+    ],
+    // The vcpkg build-native route writes the Release binary into the Windows
+    // build tree, not the Linux build directory the shared route uses. The
+    // separators are forward slashes (valid on every platform) so the directory
+    // joins cross-platform; the host's path module normalizes them on use.
+    buildDir: 'build-windows/apps/Release',
+    binary: 'ninfer-serve.exe',
+    // pwsh.exe (PowerShell 7+) is the modern shell the vcpkg build tooling
+    // expects; the legacy powershell.exe (Windows PowerShell 5.1) lacks it.
+    shell: 'pwsh.exe',
+    // The Windows local build is the vcpkg route: the winget toolchain (CMake,
+    // Ninja, the MSVC compiler, the CUDA toolkit) plus the hf CLI and git. The
+    // vcpkg manifest pulls the ffmpeg and curl dev libraries, so the Linux
+    // pkg-config/ffmpeg/curl deps do not ride the Windows list.
+    deps: [
+        SYSTEM_DEPS.cmake,
+        SYSTEM_DEPS.ninja,
+        SYSTEM_DEPS.visualStudio,
+        SYSTEM_DEPS.cudaToolkit,
+        SYSTEM_DEPS.hfCli,
+        SYSTEM_DEPS.git,
+    ],
+};
+/**
+ * ninferWindowsBinary returns the NInfer launch binary on Windows: the path
+ * relative to the checkout root (the engine directory the spawn runs in) where
+ * the vcpkg build-native route writes the Release binary,
+ * `build-windows/apps/Release/ninfer-serve.exe`. The directory and the .exe
+ * name both come from the Windows profile, so the build tree and the spelling
+ * have one home. `join` keeps the result cross-platform: the host's path module
+ * normalizes the separators, so the spawn resolves it on Windows, Linux, and
+ * macOS alike.
+ */
+export function ninferWindowsBinary() {
+    const binary = NINFER_WINDOWS.binary ?? 'ninfer-serve.exe';
+    const buildDir = NINFER_WINDOWS.buildDir;
+    return buildDir !== undefined ? join(buildDir, binary) : binary;
+}
+//# sourceMappingURL=ninferWindows.js.map

package/packages/providers/lib/engines/strata/strata.d.ts

@@ -0,0 +1 @@
+

package/packages/providers/lib/engines/{strata.js → strata/strata.js}

@@ -9,7 +9,7 @@
  *
  * The data is the surface; the `StrataAdapter` composes it into a `LaunchPlan`.
  * Adding a flag here is a data edit, never an adapter rewire.
- * @module dsh-plugin-local-infer/providers/strata
+ * @module dsh-plugin-local-infer/providers/engines/strata/strata
  */
 /**
  * The model families Strata serves. `qwen` is the Qwen3.8-Flash-Next family
@@ -70,7 +70,10 @@ export const STRATA_ACCESS_OPTIONS = [
  * spelling is the `strata launch` flag the binary and source-build modes pass;
  * the `toEnv` spelling is the container variable the docker mode passes. A
  * spec with no `toEnv` (access, dataDir) has no docker counterpart, and a spec
- * with no `toArgv` (port) is spelled by the adapter from the value.
+ * with no `toArgv` (port) is spelled by the adapter from the value. The shared
+ * specs declare both deploy targets (`cli` and `env`), so the binary and
+ * source-build plans spell the flags and the docker plan carries the env vars;
+ * `access`, `dataDir`, and `port` stay `cli`-only.
  */
 export const STRATA_PARAMETERS = [
     {
@@ -88,6 +91,7 @@ export const STRATA_PARAMETERS = [
         // The port contributes no flag of its own: renderLaunch spells the local
         // --port and the docker host-port mapping from this value, and the health
         // URL and container name derive from it too.
+        deploy: { target: 'cli' },
     },
     {
         key: 'family',
@@ -98,6 +102,7 @@ export const STRATA_PARAMETERS = [
         group: 'Model',
         toArgv: (value) => ['--family', String(value)],
         toEnv: (value) => ['FAMILY', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'context',
@@ -109,6 +114,7 @@ export const STRATA_PARAMETERS = [
         // envFromSpecs only calls toEnv when the value is set, so the pair is
         // always well-formed here.
         toEnv: (value) => ['CONTEXT', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'vision',
@@ -119,6 +125,7 @@ export const STRATA_PARAMETERS = [
         group: 'Engine',
         toArgv: (value) => ['--vision', String(value)],
         toEnv: (value) => ['VISION', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'parallel',
@@ -128,6 +135,7 @@ export const STRATA_PARAMETERS = [
         group: 'Concurrency',
         toArgv: (value) => (value === undefined ? [] : ['--parallel', String(value)]),
         toEnv: (value) => ['PARALLEL', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'gpu',
@@ -137,6 +145,7 @@ export const STRATA_PARAMETERS = [
         group: 'Engine',
         toArgv: (value) => (value ? ['--gpu', String(value)] : []),
         toEnv: (value) => ['GPU', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'tune',
@@ -147,6 +156,7 @@ export const STRATA_PARAMETERS = [
         group: 'Engine',
         toArgv: (value) => ['--tune', String(value)],
         toEnv: (value) => ['TUNE', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'access',
@@ -157,6 +167,7 @@ export const STRATA_PARAMETERS = [
         group: 'Engine',
         // local is the engine default, so the bare value spells no flag.
         toArgv: (value) => (value === 'local' ? [] : ['--access', String(value)]),
+        deploy: { target: 'cli' },
     },
     {
         key: 'apiKey',
@@ -166,6 +177,7 @@ export const STRATA_PARAMETERS = [
         group: 'Engine',
         toArgv: (value) => (value ? ['--api-key', String(value)] : []),
         toEnv: (value) => ['API_KEY', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'modelPath',
@@ -175,6 +187,7 @@ export const STRATA_PARAMETERS = [
         group: 'Artifacts',
         toArgv: (value) => (value ? ['--model-path', String(value)] : []),
         toEnv: (value) => ['MODEL_PATH', String(value)],
+        deploy: [{ target: 'cli' }, { target: 'env' }],
     },
     {
         key: 'dataDir',
@@ -183,6 +196,7 @@ export const STRATA_PARAMETERS = [
         form: { kind: 'path' },
         group: 'Artifacts',
         toArgv: (value) => (value ? ['--data-dir', String(value)] : []),
+        deploy: { target: 'cli' },
     },
 ];
 /**
@@ -194,4 +208,57 @@ export const STRATA_PARAMETERS = [
 export function strataModelKey(config) {
     return typeof config.model === 'string' ? config.model : '';
 }
-//# sourceMappingURL=strata.js.map
+/**
+ * strataDefaults resolves the source-build launch values (family, vision,
+ * context) from the config, falling back to the parameter surface's
+ * defaultValue when the config names no value. The surface is the single home
+ * for the defaults, so the adapter's renderLaunch never hard-codes one.
+ * `context` carries no surface default (the engine picks the largest that
+ * fits), so it resolves to undefined when the config names no value.
+ */
+export function strataDefaults(config) {
+    const resolve = (key) => {
+        const value = config[key];
+        if (typeof value === 'string' && value !== '') {
+            return value;
+        }
+        const spec = STRATA_PARAMETERS.find((candidate) => candidate.key === key);
+        return typeof spec?.defaultValue === 'string' ? spec.defaultValue : undefined;
+    };
+    const family = resolve('family');
+    const vision = resolve('vision');
+    // The surface declares string defaults for family and vision, so the
+    // resolver returns a string for both. Reaching the guard means a spec lost
+    // its defaultValue, so the launch cannot be spelled; fail fast at render
+    // time rather than emit a broken argv.
+    if (family === undefined || vision === undefined) {
+        const missing = family === undefined ? 'family' : 'vision';
+        throw new Error(`the strata surface lost its ${missing} default`);
+    }
+    return { family, vision, context: resolve('context') };
+}
+/**
+ * strataSourceLaunchArgs renders the source-build wrapper argv shared by every
+ * OS. The wrapper's `--vision` takes yes|no|gpu|cpu, so the surface's on|off
+ * maps onto it (gpu and cpu pass through). The command name is the one
+ * OS-specific piece, supplied by the caller (setup.sh on Linux/Mac,
+ * START-HERE.bat on Windows).
+ */
+export function strataSourceLaunchArgs(command, args) {
+    // The wrapper's --vision takes yes|no|gpu|cpu; the surface's on|off maps onto
+    // it (gpu and cpu pass through).
+    const visionFlag = args.vision === 'on' ? 'yes' : args.vision === 'off' ? 'no' : args.vision;
+    return [
+        command,
+        '--yes',
+        ...(args.model !== '' ? ['--model', args.model] : []),
+        ...(args.family !== 'qwen' ? ['--family', args.family] : []),
+        '--vision',
+        visionFlag,
+        ...(args.context !== undefined ? ['--context', args.context] : []),
+        '--port',
+        String(args.port),
+        ...args.customArgs,
+    ];
+}
+//# sourceMappingURL=strata.js.map

package/packages/providers/lib/engines/{strataAdapter.d.ts → strata/strataAdapter.d.ts}

@@ -13,10 +13,10 @@
  * queries the running engine's model endpoint through the terminal for the id
  * it actually loaded (family and size sized to the host), so the registrar
  * publishes the served model, not a placeholder.
- * @module dsh-plugin-local-infer/providers/engines/strataAdapter
+ * @module dsh-plugin-local-infer/providers/engines/strata/strataAdapter
  */
-import { EngineAdapter } from '../../../core/lib/index.js';
-import type { Config, DeployOptions, DeployResult, EngineLaunchSignature, EngineLaunchState, EnginePlatformConfig, HealthCheckOptions, HealthResult, HardwareProfile, LaunchPlan, LaunchProgress, LifecycleHost, ParameterSpec } from '../../../core/lib/index.js';
+import { EngineAdapter } from '../../../../core/lib/index.js';
+import type { CommandLogger, Config, DeployOptions, DeployResult, EngineLaunchSignature, EngineLaunchState, EnginePlatformConfig, HealthCheckOptions, HealthResult, HardwareProfile, LaunchPlan, LaunchProgress, LifecycleHost, ParameterSpec } from '../../../../core/lib/index.js';
 /**
  * The Strata docker image the adapter pulls and runs. The image is the
  * upstream GitHub Container Registry artifact for the newest release's CUDA 13
@@ -90,9 +90,8 @@ export declare class StrataAdapter extends EngineAdapter {
     renderLaunch(config: Config, _hw: HardwareProfile): LaunchPlan;
     deploy(plan: LaunchPlan, platform?: EnginePlatformConfig, onProgress?: LaunchProgress, options?: DeployOptions): Promise<DeployResult>;
     healthCheck(plan: LaunchPlan, options?: HealthCheckOptions): Promise<HealthResult>;
-    stop(plan: LaunchPlan): Promise<void>;
+    stop(plan: LaunchPlan, log?: CommandLogger): Promise<void>;
     private buildMode;
     private port;
-    private planKey;
 }
-//# sourceMappingURL=strataAdapter.d.ts.map
+//# sourceMappingURL=strataAdapter.d.ts.map