为什么选择 abyss
TIP
- abyss 是一个精心设计、自成体系的 Scoop bucket
- 它对 Scoop 的一些机制做了扩展性的设计
它不只是一个 bucket
当我们谈论第三方 Scoop bucket 时，通常的印象是：
- 添加一些官方没有的清单
- 或者对官方清单做一些小的调整
而 abyss 不同，它对 Scoop 做了一些扩展性的设计，以解决官方清单长期存在的一些问题
重新设计了什么
数据持久化
- Scoop 的 Persist 机制只能持久化安装目录下的数据
- 但大多数现代应用的数据存储在 Windows 标准目录中，而官方的变通方案各有问题
C:\Users\<username>\AppData\Roaming\xxxC:\Users\<username>\AppData\Local\xxxC:\Users\<username>\Documents\xxxC:\Users\<username>\xxx- ...
abyss 设计了统一的 Link 机制，直接在数据原始位置创建文件系统链接
详细说明: 数据持久化
应用安装方式
- Scoop 的标准方式是将安装包作为压缩包解压
- 但部分应用不适合这种方式，强行解压可能导致功能异常
- 例如: NanaZip
- 只有使用标准 msixbundle 安装，才能正常注册右键菜单
abyss 会根据应用类型选择合适的安装方式，而非一刀切地解压
详细说明: 应用安装方案
清单状态控制
- Scoop 清单通过 Github Actions 自动更新，但缺乏显式的状态控制
- 当清单出现问题或被重命名时，无法主动通知用户，用户可能在不知情的情况下受影响
abyss 可以通过状态标记暂停问题清单、引导重命名清单，保护用户免受影响
详细说明: 清单状态控制
清单命名规则
- 官方清单使用简单的名称，例如
vscode.json、git.json - 这种方式在处理分支版本时不够灵活，且没有明确归属
abyss 参考了 winget-pkgs 的命名方式，采用 Publisher.PackageIdentifier 格式
详细说明: 清单命名
不同的使用体验
使用官方清单时，用户往往需要记住一些"最佳实践"：
- 不要使用应用的内置更新，应该用
scoop update - 某些应用的功能可能受限（如右键菜单、系统集成等）
- 安装路径不标准，可能导致其他应用找不到
这些是用户在长期使用中形成的固有观念
但在 abyss 中，这些问题本身就不存在：
- 应用通过标准安装程序安装，可以正常使用内置更新
- 功能完整，没有因为安装方式导致的兼容性问题
- 安装路径符合系统标准，其他应用可以正常调用
这不是让用户去适应新的规则，而是让应用回归到它本该有的状态