[FEATURE REQUEST] Add Evergreen as a package source via the Evergreen API

[JonathanPitre]

Please confirm these before moving forward.

• I have searched for my feature proposal and have not found a work-in-progress/duplicate/resolved/discarded issue.
• This proposal is a completely new feature. If you want to suggest an improvement or an enhancement, please use this template.

Describe the new feature

Add Evergreen as an optional UniGetUI package source, using the public Evergreen REST API (same data as Get-EvergreenApp).

• Product: https://eucpilots.com/evergreen/
• API docs: https://eucpilots.com/evergreen/api
• Base URL: https://evergreen-api.stealthpuppy.com
• Catalog today: 568 apps, refreshed about every 8 hours from official vendor update sources (not a community feed).

Evergreen is not Chocolatey/Winget. It does not own an install/uninstall database. Each app is a list of current vendor installers: version, architecture, channel, type (msi/exe), SHA256, size, and a direct URI.

Suggested UX (optional source, off by default)

1. Discover: GET /apps → package list (Name, Application, Link).
2. Details / install / update: GET /app/{appName} → pick one variant, download URI, run the installer (same path UniGetUI already uses for download-then-install).
3. Default variant: current OS architecture, then Channel=Stable / Release=Enterprise when those fields exist. Let the user override channel/arch/type in package options.
4. Integrity: verify SHA256 when the payload includes it.

Example (Microsoft Edge Enterprise x64 Stable):

GET https://evergreen-api.stealthpuppy.com/app/MicrosoftEdge
User-Agent: UniGetUI/{version}

Returns rows such as Version, Channel, Release, Architecture, Type, SHA256, URI.

API constraints UniGetUI would need to respect

• A custom User-Agent is required. Default PowerShell/curl/browser UAs are blocked. Please send something identifiable, e.g. UniGetUI/3.x (not a generic Mozilla/...).
• The API runs on Cloudflare Workers’ free tier (100,000 requests/day) and is documented as for development, not distributed endpoints. A built-in UniGetUI manager that polled every app on every refresh would get UniGetUI blocked and starve other users.
  • Cache GET /apps and GET /app/{name} locally for at least 8 hours (matches their refresh).
  • Do not enumerate /app/{name} for the full catalog on startup; fetch per package on search/details/update check.
  • Optional fallback: call the Evergreen PowerShell module (Get-EvergreenApp) so each machine hits vendor APIs directly instead of the shared Worker. That is the documented production-safe path; the REST API is the easy integration.
• Variant explosion: some apps have a handful of rows (VMwareTools = 2); others have thousands (MozillaFirefox was 3000+). Filtering by arch/channel/locale is required or the UI will be unusable.
• Uninstall / “installed packages” will be weaker than Winget/Scoop. Detect via ARP / existing UniGetUI installed-package matching, or treat Evergreen as discover + download + install + version-compare only.

I searched evergreen on this issue tracker and found no duplicate.

Describe how this new feature could help users

Winget (and the other managers) are great for many desktop apps, but they often lag or omit enterprise SKUs and vendor-direct installers: Edge Enterprise MSI, Adobe Acrobat/Reader channels, VMware Tools, FSLogix, Citrix Workspace, etc. Evergreen’s point is exactly that gap: “current version + official download URL from the vendor,” with hashes.

For IT / MSP / image-building users who already live in UniGetUI, this would mean:

• One UI to find the vendor-current build instead of hunting vendor sites or maintaining one-off scripts.
• Safer downloads (SHA256 on most payloads) than an unverified web link.
• A complement to Winget, not a replacement: keep Winget/Scoop/Chocolatey for apps they cover well; use Evergreen when you need the official current installer.

Happy to iterate on scope (discover-only vs full install/update) if a thin first slice is more realistic given the shared API limits.