Glue
The goal of Glue is simple: keep the Scoop ecosystem that already works well, and make the install runtime faster and leaner for everyday use.
Background
On Windows, developers install tools through many different mechanisms: installers, zip archives, scripts, or platform-specific package managers.
Scoop showed that a user-space, manifest-driven model works well. Packages are described through JSON manifests stored in community buckets, applications install under the user's profile directory, administrator rights are usually unnecessary, and the command set stays small and predictable.
That model proved successful. Today, the Scoop ecosystem contains thousands of packages maintained by a large community. The manifests, bucket structure, and package conventions are the valuable part of the ecosystem — and they are what Glue builds on.
Glue is a separate install runtime for that ecosystem. It does not take over an existing Scoop installation or its on-disk workspace.
In everyday use, two limitations become noticeable:
- Large archives are often downloaded through a single connection, leaving available bandwidth unused.
- Reinstalling packages can repeatedly copy identical files even when the package contents have not changed.
Glue was created to address these two problems.
Compatibility
Glue reads existing Scoop bucket manifests and follows the same package conventions.
Commands and bucket workflows are intentionally familiar. For example:
glue bucket add extras
glue install nodejsIf you already know Scoop, you can reuse the same public buckets and muscle memory — no separate catalog to invent.
Packages installed by Glue live under their own root:
%USERPROFILE%\.glueThat is independent of Scoop's usual workspace (typically under %USERPROFILE%\scoop). Glue keeps its own apps, shims, and content store. Installing with Glue does not move or rewrite packages already managed by Scoop.
The on-disk layout follows a similar idea — applications, shims, shared content — but inside the Glue root. Installed commands are exposed through Glue's shim layer, and user environment integration is handled automatically for Glue.
What is different under the hood
Glue is a new implementation written in Go. The main differences are in how packages are downloaded and stored:
- Content-addressed storage — Glue stores downloaded content by hash. When the same data is needed again, it reuses the existing blobs instead of downloading or copying them again. That cuts unnecessary disk use and makes repeated installs much faster.
- Parallel downloading — Large files can be fetched over multiple HTTP connections with range requests and resume support, so installs make better use of available bandwidth.
- Native shims — Installed commands land on PATH through small native shim binaries, without manual environment edits.
Bucket maintainers keep publishing the same Scoop manifests. Glue uses those definitions when it installs into %USERPROFILE%\.glue.
How Glue relates to Scoop
Glue and Scoop share the same package sources: the same public buckets, manifests, and install conventions.
They do not share the same local workspace. Scoop established the bucket model; Glue is a separate Go runtime with its own storage and download architecture.
You can keep Scoop as-is and try Glue in parallel. Each tool manages only the packages it installed under its own directory.
Glue, Chocolatey, and WinGet
Windows package managers often appear together, but they sit in different ecosystems.
Glue is built for Scoop buckets: developer tools, command-line utilities, and user-space installs.
Chocolatey uses its own package format and repository, and is commonly used for broader software deployment — including system-wide setups.
WinGet targets general Windows software distribution and integrates closely with the Windows ecosystem.
If your sources are Scoop buckets and you want a more efficient install engine without changing those sources, Glue is built for that workflow.
Desktop experience
The command-line interface is the primary Glue experience.
For a graphical workflow, Gluestick Desktop provides a GUI on the same Glue engine and storage — browse buckets, search, install, and remove packages without leaving the Scoop-compatible model.
Both interfaces use the same package store under:
%USERPROFILE%\.gluePackage index and ecosystem
The package index on gluestick.sh is generated from bucket data used for Glue testing and daily development.
Scoop buckets remain independent repositories. Glue consumes those package definitions directly.
License and scope
Glue is MIT licensed.
The CLI source code is available at gluestick-sh/cli.
Glue is a Scoop-compatible runtime optimized for modern storage and network workloads.
Install
If you already use Scoop, try Glue alongside it — same public buckets, separate local store and engine. If you are new to manifest-based package management on Windows, the commands should feel familiar immediately.
irm https://gluestick.sh/install.ps1 | iexGlue is for developers who like Scoop's simplicity and want an install runtime that makes better use of disk and bandwidth.
Comments