Glue
Glue 的目标很简单：保留已经运转良好的 Scoop 生态，让日常使用的安装运行时更快、更省。
背景
在 Windows 上，开发者通过各种方式安装工具：安装器、zip 压缩包、脚本，或各平台专属的包管理器。
Scoop 证明了「用户空间 + 清单驱动」的模式行得通：包用存放在社区 bucket 里的 JSON 清单描述，应用安装在用户主目录下，通常不需要管理员权限，命令集小而可预期。
这个模式获得了成功。今天，Scoop 生态包含数千个由庞大社区维护的包。清单、bucket 结构和包约定是这个生态中真正有价值的部分，Glue 正是建立在这些之上。
Glue 是这个生态的一个独立安装运行时，它不会接管现有的 Scoop 安装或其磁盘工作区。
在日常使用中，两个限制会逐渐显现：
- 大文件通常只通过单一连接下载，可用带宽没有被充分利用。
- 重装包时，即使包内容完全没有变化，也会反复复制相同的文件。
Glue 就是为了解决这两个问题而生。
兼容性
Glue 直接读取现有 Scoop bucket 清单，遵循相同的包约定。
命令和 bucket 工作流刻意保持熟悉，例如：
glue bucket add extras
glue install nodejs如果你已经了解 Scoop，可以复用同样的公共 bucket 和肌肉记忆，不需要另起炉灶的包目录。
Glue 安装的包存放在自己的根目录下：
%USERPROFILE%\.glue这与 Scoop 常用的工作区（通常在 %USERPROFILE%\scoop）相互独立。Glue 拥有自己的 apps、shims 和内容存储，用它安装不会移动或改写 Scoop 已管理的包。
磁盘布局遵循相似的思路：应用、shims、共享内容只是全部位于 Glue 根目录内。已安装的命令通过 Glue 的 shim 层暴露，用户环境集成由 Glue 自动处理。
引擎之下，有什么不同
Glue 是用 Go 重新实现的新程序，主要差异在于包的下载和存储方式：
- 内容寻址存储：Glue 按哈希存储下载的内容。同样的数据再次需要时，直接复用已有的文件，而不是重新下载或复制，减少不必要的磁盘占用，重复安装快得多。
- 并行下载：大文件可通过多个 HTTP 连接分段获取并支持断点续传，安装时能更充分地利用带宽。
- 原生 shim：安装的命令通过小型原生 shim 二进制加入
PATH，无需手动修改环境变量。
bucket 维护者继续发布同样的 Scoop 清单，Glue 用这些定义把包安装到 %USERPROFILE%\.glue。
Glue 与 Scoop 的关系
Glue 和 Scoop 共享同样的包来源：同样的公共 bucket、清单和安装约定。
但两者不共享同一个本地工作区。Scoop 建立了 bucket 模式；Glue 是一个有自己存储和下载架构的独立 Go 运行时。
你可以让 Scoop 保持原样、并行试用 Glue。每个工具只管理自己目录下安装的包。
Glue、Chocolatey 与 WinGet
Windows 包管理器经常被放在一起谈论，但它们其实处于不同的生态。
Glue 为 Scoop bucket 而生：开发工具、命令行工具和用户空间安装。
Chocolatey 使用自己的包格式和仓库，常用于更广泛的软件部署，包括系统级安装。
WinGet 面向通用 Windows 软件分发，与 Windows 生态紧密集成。
如果你的包来源是 Scoop bucket，想要一个更高效的安装引擎而又不更换来源，Glue 就是为这个工作流打造的。
桌面体验
命令行界面是 Glue 的主要体验。
需要图形化工作流时，Gluestick Desktop 在同一个 Glue 引擎和存储之上提供 GUI，浏览 bucket、搜索、安装和移除包，全程不脱离 Scoop 兼容模式。
两个界面共用同一个包存储：
%USERPROFILE%\.glue包索引与生态
gluestick.sh 上的包索引由 Glue 测试和日常开发使用的 bucket 数据生成。
Scoop bucket 仍是独立的仓库，Glue 直接使用那些包定义。
许可与范围
Glue 采用 MIT 许可证。
CLI 源码托管在 gluestick-sh/cli。
Glue 是一个面向现代存储与网络负载优化的 Scoop 兼容运行时。
安装
已经在用 Scoop？可以并行试用 Glue，同样的公共 bucket，独立的本地存储和引擎。如果你刚开始接触 Windows 上基于清单的包管理，这些命令会让你立刻感到熟悉：
irm https://gluestick.sh/install.ps1 | iexGlue 属于既喜欢 Scoop 的简洁、又希望安装运行时更省磁盘和带宽的开发者。
Comments