Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[RFC] Standalone Windows installer + tray Manager for OVMS (install / repair / uninstall / update)

Abierto
  • ¿Algo no está bien?
#4,347 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
csharp, python
Área
build-system, desktop, operating-systems

Línea de trabajo

Comienza con packaging/windows/OVMS_WINDOWS_INSTALLER_MANAGER_PLAN.md en PR #4350 y el flujo de trabajo de Updates en #4351; primero resuelve con los maintainers las cuestiones sobre el alcance y el modelo de instalación. Los criterios de aceptación enumerados definen cuándo se considera terminado: instalación por usuario, reparación y desinstalación, controles del Manager, configuración atómica, diagnósticos y rollback de actualizaciones por etapas.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Propose adding a standalone, self-contained Windows installer / uninstaller / repairer plus a tray-based OVMS Manager GUI, so Windows users can install a working, version-matched OVMS stack; run, monitor, and configure it; repair a broken install; and update it — all without manual unzip/env/config steps. This complements (does not replace) the portable ovms.zip.

Reference implementation: PR #4350. The Updates workflow is detailed in #4351.

Motivation

On Windows, OVMS ships only as a portable archive. There is no guided installer, no Apps & Features uninstaller, no repair path, and no update path. Non-expert users must manually unzip, set environment variables, wire up startup, and hand-edit config to serve a model. Because OVMS is a version-matched stack (ovms.exe + OpenVINO runtime + GenAI + tokenizers + Python), mixing DLLs across releases is a frequent failure. This is a real barrier to local/desktop adoption compared to tools like Ollama.

Architecture

Keep the server headless; add a thin Windows UX layer around it:

OVMS-Setup.exe   installs the payload, writes first-run config, registers uninstaller/startup
OVMS.Manager.exe owns the tray icon + GUI; controls start/stop; edits settings; repair/update
ovms.exe         unchanged model server process
  • Program files: %LOCALAPPDATA%\Programs\OVMS
  • User data: %LOCALAPPDATA%\OVMS (settings.json, models\config.json, logs\, packages\, diagnostics\, runtime.json)
  • Per-user, no elevation for the default flow (HKCU). Machine-wide/service mode is a follow-up requiring elevation.

Installer (Inno Setup, build-time-only dependency)

  • Installs the existing python_on package as a single version-matched payload — no downloads at install time.
  • Modern wizard UI with OpenVINO branding; existing-install detection with a Repair/upgrade vs. Uninstall choice page.
  • Apps & Features uninstaller with a 3-way data choice (preserve all / keep models / remove all).
  • Repairer: verify required files, restore from a cached pristine package (%LOCALAPPDATA%\OVMS\packages\source), re-run ovms.exe --version.
  • Optional PATH entry and start-at-login; Start Menu shortcuts (Open / Start / Stop / Repair / Uninstall).

Manager GUI (.NET WinForms, tray app)

App-shell with a left nav rail and five pages (all responsive; process/HTTP work off the UI thread):

  • Dashboard — status/pid, REST endpoint, gRPC, models served, health (GET /v3/models), package variant, runtime mode; Start / Stop / Restart / Open Logs / Open Model Folder; auto-refresh.
  • Settings — REST/gRPC ports, bind address, log level/path, model repository (Browse), startup mode, show-tray, start-at-login; atomic save with .bak, restart prompt for command-line-affecting changes, non-local bind warning.
  • Logs — tails the server log with auto-scroll, line count, open-folder/clear.
  • Advanced — environment info (dirs, versions, effective command line + Copy) and maintenance actions (Repair / Validate / Export Diagnostics bundle).
  • Updates (#4351) — installed vs. latest for Base package / Model Server / GenAI, release-note links, and a validated staged upgrade (download → verify → back up → replace → validate → rollback on failure).

Supporting scripts (packaging/windows/scripts)

configure-ovms, start-ovms/stop-ovms (process or service), set-path, ovms-env, install-service/uninstall-service, validate-install, repair-package, upgrade-package, uninstall-ovms. Atomic JSON writes, runtime ownership via runtime.json, port preflight, local-only default bind.

Non-goals (initial)

  • Not turning ovms.exe into a GUI app; not replacing ovms.zip.
  • Not mixing arbitrary OpenVINO/GenAI/OVMS DLL versions — the package is the unit of install/upgrade.
  • Windows Service mode is scaffolded but requires elevation (follow-up); machine-wide install is a separate mode.
  • Updating the Manager app itself, and background/silent auto-update, are follow-ups.

Design doc

Full architecture and phased plan: packaging/windows/OVMS_WINDOWS_INSTALLER_MANAGER_PLAN.md (in PR #4350).

Acceptance criteria

  • Fresh per-user install succeeds without elevation; ovms.exe --version works afterward.
  • Existing-install detection offers Repair/upgrade vs. Uninstall.
  • Uninstall removes program files, PATH/startup entries, and shortcuts; honors the 3-way data choice.
  • Repair restores missing files from the cached package and re-validates.
  • Manager starts/stops/restarts the server and reflects live health.
  • Settings persist atomically with backup; command-line-affecting changes prompt for restart.
  • Diagnostics bundle exports settings/logs/versions/runtime state.
  • Updates page + staged upgrade behave per #4351 (with rollback).
  • No build artifacts committed; Inno Setup is a build-time-only dependency.

Questions for maintainers

  • Is an in-repo Windows installer + manager in scope for model_server, or preferred as a separate companion project?
  • Per-user (proposed default) vs. machine-wide as the primary install model?
  • Ship both python_on and python_off variants, or one installer that can fetch the other variant?
  • Preferred source of truth for release metadata/checksums used by the update checker?

Happy to adjust scope based on direction.

Lenguaje dominante
C++
Estrellas
932
Forks
278
Merge medio
3 d 5 h
PR fusionados (30 d)
70

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openvinotoolkit/model_server

Todos los issues de openvinotoolkit/model_server

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.