Skip to content

Show current and new version in Studio installer banner - #9914

Open
Greninja44 wants to merge 2 commits into
unslothai:mainfrom
Greninja44:feat/studio-installer-version-banner
Open

Show current and new version in Studio installer banner#9914
Greninja44 wants to merge 2 commits into
unslothai:mainfrom
Greninja44:feat/studio-installer-version-banner

Conversation

@Greninja44

Copy link
Copy Markdown
Contributor

Issue

Closes #9910.

The Windows Unsloth Studio installer (install.ps1) printed the banner and went straight into winget available, python ... already installed, etc., with no indication of what version of Studio was already installed or what version this run was about to install:

πŸ¦₯ Unsloth Studio Installer (Windows)
────────────────────────────────────────────────────
winget available
python Python 3.13 already installed
...

Why

Users had no visibility into what they currently had versus what they were about to get, especially on an upgrade β€” the first hint of a version only showed up deep in the log, after the fact.

Changes

  • Added Get-StudioVersionProbe, a small shared PowerShell function wrapping the existing Python probe (studio.install_manifest.installed_version_probe, falling back to importlib.metadata) that already ran after install. It's now used in two places: a new pre-install check, and the pre-existing post-install report (refactored to call it instead of duplicating the embedded Python).
  • "current version": queries whatever's already at $VenvDir\Scripts\python.exe, before anything is touched. No prior install β†’ not installed. A probe that can't run cleanly (missing venv, broken interpreter) β†’ unknown β€” this is purely informational and never blocks or alters the actual install.
  • "new version": the $_unslothDesktopInstallSpec / $_unslothReleaseInstallSpec computation (env override, else the pinned unsloth>=... floor) was hoisted up near the banner instead of duplicated β€” the exact same variable is still consumed, unchanged, by the real uv pip install call further down, so the banner can't drift from what actually gets installed.
  • Output now appears immediately after the banner, before winget available:
    πŸ¦₯ Unsloth Studio Installer (Windows)
    ────────────────────────────────────────────────────
    current version: 1.2.22
    new version: 1.2.23
    winget available
    
  • No changes to install, rollback, GPU/torch, or venv-creation logic.

Testing

  • Full-file syntax validation ([System.Management.Automation.Language.Parser]::ParseFile) on both PowerShell 7.4.6 and real Windows PowerShell 5.1 (build 26100) β€” passes on both.
  • tests/test_installer_profile_hardening.py::test_install_ps1_parses β€” passes.
  • New tests/test_installer_version_banner.py (6 tests): banner lines are ordered between the title and winget; the install-floor literal isn't duplicated; a fresh install reports not installed + the pinned floor; UNSLOTH_DESKTOP_BACKEND_VERSION override is reflected in "new version"; an existing venv reports its real installed version through the probe; a broken interpreter degrades to unknown without crashing.
  • Manually exercised all four probe scenarios (fresh / existing install / env override / broken interpreter) and rendered the full banner end-to-end on real Windows PowerShell 5.1 against a real Python interpreter β€” output matches expectations exactly, including the real installed package version being reported correctly.
  • Updated tests/test_installer_unsloth_version.py::test_windows_version_reporter_uses_distribution_metadata to account for the post-install block now calling the shared helper; verified it exercises identical behavior to before the refactor.
  • Full installer test suite run locally: all passing tests still pass; no regressions introduced.

install.ps1 printed straight from the banner into "winget available" with
no indication of what Studio version was already installed or what this
run was about to install (unslothai#9910).

Add a shared Get-StudioVersionProbe, used both by a new pre-install check
and by the existing post-install report (refactored to call it instead of
duplicating the embedded Python), so "current version" always reflects
whatever venv is actually on disk. "New version" reuses the same
$_unslothReleaseInstallSpec the real install command further down
consumes (hoisted, not duplicated), so the two can never drift apart.

A fresh install shows "not installed"; a probe that can't run cleanly
(missing venv, broken interpreter) degrades to "unknown" without ever
blocking or altering the install itself.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature] Unsloth studio installer shoud show current version and version installing

3 participants