You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Install specific Scoop versions and update pinned installs - #5619
Scoop has long supported scoop install bucket/app@version, and since v0.6.0 it resolves the exact old manifest from the bucket's git history. UniGetUI never exposed it, and the README chart marked Scoop as not supporting version choice at all.
Typed version field. Scoop can't list the versions it can install, so the version dropdown had nothing to offer. A new CanListVersions capability separates "can install a chosen version" from "can list versions". When it is false:
the install options dialog, the terminal UI and the catalog editor's Pin version dialog show a text field instead of a list;
GetVersions returns nothing instead of asking the manager.
A typed version still goes through the shell-safety check that every version on a shell-interpreted manager gets, so 1.7.1;calc is refused.
Pinned installs. A Scoop app installed with @version leaves Scoop's normal tracking: scoop list reports its source as <auto-generated>, scoop status never reports it as outdated, and a plain scoop update keeps the pinned version. That already broke apps pinned from the command line. UniGetUI built the spec <auto-generated>/app, which the package-spec check refuses, so uninstalling them or loading their details failed.
Pinned apps now:
are matched to the bucket Scoop itself would pick (known buckets first, then alphabetical) by reading the bucket manifests on disk, and are listed under that bucket;
are offered an update when that bucket has a newer version;
update with scoop update bucket/app --force, which on Scoop v0.6.0+ moves a pinned app back to the bucket's latest version.
Older Scoop would only reinstall the pinned version, so pinned updates are offered only when scoop --version reports v0.6.0 or later. On older Scoop, pinned apps behave as before, except that uninstall now works.
README chart. In the "Choose version to install" row, Scoop goes from ❌ to ⚠️ and Cargo from ❌ to ✅. Scoop gets ⚠️ because a version that isn't in the bucket's git history can't be resolved. Cargo has supported custom versions in UniGetUI all along.
Testing
Checked against real Scoop 0.6.0: a pinned jq@1.7.1 install, how scoop list and scoop status report it, and scoop update -f main/jq bringing it back to 1.8.2.
Unit tests for the @version spec, the refused unsafe version, bucket resolution (including bucket order on disk under a fake SCOOP folder), --force, the v0.6.0 check, and not offering a downgrade.
A new terminal-UI end-to-end test types a version and installs it; the fake Scoop now behaves like the real one.
Full terminal-UI and package-engine suites pass, and both dotnet format checks are clean.
Tested by hand in the running app.
Not covered
"Download installer" for a pinned app still downloads the bucket's latest version.
The bucket lookup uses the SCOOP environment variable or ~/scoop, not a custom root_path in Scoop's config file, like the existing install-location lookup.
The NativeAOT publish and macOS/Linux builds weren't run.
The reason will be displayed to describe this comment to others. Learn more.
🟡 Changes recommended
Saved install-version pins can cause updates to report the old installed version, while pinned-update detection can expose held apps to updates and miss pinned installs present in both user and global scopes.
Adds specific-version installation for Scoop across UniGetUI’s desktop, terminal, and catalog interfaces, and restores update handling for pinned installs. It also corrects the feature chart highlighted in #5615.
Changes:
Separates version installation from version listing, enabling typed version fields.
Resolves pinned Scoop apps to buckets and offers forced updates on Scoop 0.6.0+.
Adds regression coverage and corrects Scoop/Cargo version-support indicators.
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
The installed-inventory cache can retain stale bucket versions during concurrent startup scans, causing newly available pinned updates to be omitted after the index refresh.
No open issues 🎉
1 previously missed issue
In code that hasn't changed since last review
Refresh bucket versions after updates before comparing cached pins
Startup loads installed packages and updates concurrently, so the 15-second installed-inventory cache can retain bucket versions read before scoop update refreshes the manifests. This comparison can then omit a newly available pinned update from the completed scan. Keep the cached pin identity, but read the current bucket version during this update pass after the index refresh.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scoop has long supported
scoop install bucket/app@version, and since v0.6.0 it resolves the exact old manifest from the bucket's git history. UniGetUI never exposed it, and the README chart marked Scoop as not supporting version choice at all.Typed version field. Scoop can't list the versions it can install, so the version dropdown had nothing to offer. A new
CanListVersionscapability separates "can install a chosen version" from "can list versions". When it is false:GetVersionsreturns nothing instead of asking the manager.A typed version still goes through the shell-safety check that every version on a shell-interpreted manager gets, so
1.7.1;calcis refused.Pinned installs. A Scoop app installed with
@versionleaves Scoop's normal tracking:scoop listreports its source as<auto-generated>,scoop statusnever reports it as outdated, and a plainscoop updatekeeps the pinned version. That already broke apps pinned from the command line. UniGetUI built the spec<auto-generated>/app, which the package-spec check refuses, so uninstalling them or loading their details failed.Pinned apps now:
scoop update bucket/app --force, which on Scoop v0.6.0+ moves a pinned app back to the bucket's latest version.Older Scoop would only reinstall the pinned version, so pinned updates are offered only when
scoop --versionreports v0.6.0 or later. On older Scoop, pinned apps behave as before, except that uninstall now works.README chart. In the "Choose version to install" row, Scoop goes from ❌ to⚠️ and Cargo from ❌ to ✅. Scoop gets ⚠️ because a version that isn't in the bucket's git history can't be resolved. Cargo has supported custom versions in UniGetUI all along.
Testing
jq@1.7.1install, howscoop listandscoop statusreport it, andscoop update -f main/jqbringing it back to 1.8.2.@versionspec, the refused unsafe version, bucket resolution (including bucket order on disk under a fakeSCOOPfolder),--force, the v0.6.0 check, and not offering a downgrade.dotnet formatchecks are clean.Not covered
SCOOPenvironment variable or~/scoop, not a customroot_pathin Scoop's config file, like the existing install-location lookup.Closes #5615