修复uv换源

[Mikachu2333]

问题描述

1. 当前uv换源不完整，仅能对uv的pypi下载进行换源，无法加速uv的python下载
2. 我的邮箱换了
3. close uv 换源不完整，还需考虑 Python 解释器本身下载地址的换源 #358 , re-close uv 换源不完整，还需考虑 Python 解释器本身下载地址的换源 #309

方案与实现

• uv.c
  • 重写 get/set/reset
  • 项目级别现同时支持 pyproject.toml 与 uv.toml
  • 新增内部 python-build-standalone 测速
  • python-install-mirror新增CNB源
  • 修正配置优先级
• uv-helper.c
  • 新增：受限 TOML 改写模块，替代原 grep/sed/PowerShell 外部命令
• uv-helper-test.c: 新增单元测试，接入 make test / just test
• Makefile / justfile: 编译 uv-helper-test.c
• doc/12-uv换源实现说明.md
• reset：实现时直接写回默认上游，未读bak文件（有意为之）

特殊的地方

1. 现在支持传入 chsrc set uv xxx
   • 若xxx仅存在于pypi，pypi自动换源+python测速换源
   • 若xxx仅存在于python，python自动换源+pypi测速换源
   • 若同时存在，自动换源两个
   • 若同时不存在，抛出错误
   • 用户手动输入：当前默认仅修改pypi，python mirror不支持手动指定
2. 上面的自动选择功能以及toml解析写入功能是AI写的，我实在写不明白了。虽然看不太明白，但我本地按各种case全测了一遍，没有发现问题，test cases也跑过没有问题。

潜在问题

1. uv-helper.c 仅处理了一般常见情况和一点点常见的edge case（话说常见了还能叫edge case么），对极限情况不予支持（intended）
2. 仅测试win，其他设备没条件测试
3. 未明确

REF

• uv index 设置
• uv python-install-mirror 设置
• uv 配置文件优先级
• uv package indexes

[github-actions]

Hi @Mikachu2333

❤️ 感谢你的贡献！我们将在最少半小时，最多5天内阅读此 PR 并回复你

[Mikachu2333]

cmd有点恶心了，竟然没法处理 ./xxx 这种路径，所以为啥 static void chsrc_backup (const char *path) 没有对路径进行标准化啊，也没相关的docs说明

[Copilot]

Pull request overview

该 PR 针对 uv recipe 修复“只换 PyPI、不换 Python 解释器下载镜像”的问题：在 uv.toml/pyproject.toml 中同时管理 [[index]] / [[tool.uv.index]] 与 python-install-mirror，并引入内部轻量 TOML 字符串改写模块与配套单测，接入现有测试入口（Makefile/just）。

Changes:

• 重写 uv 的 get/set/reset 流程：项目级同时支持 uv.toml 与 pyproject.toml（[tool.uv]），并补齐 python-install-mirror 的换源。
• 新增 uv-helper.c 作为受限 TOML 读写/改写工具，替代外部 grep/sed/PowerShell 依赖，并新增对应单元测试。
• 补充文档与测试接入（Makefile/justfile），并做少量仓库维护性变更（gitignore、编辑器设置、贡献者信息更新）。

Reviewed changes

Copilot reviewed 13 out of 15 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
test/xy.c	更新测试文件头部的作者/贡献者联系方式
test/uv-helper-test.c	新增 uv-helper 的单元测试（覆盖 uv.toml/pyproject.toml 与 CRLF 等场景）
src/recipe/recipe-template.c	更新模板文件头部的贡献者联系方式
src/recipe/lang/Python/uv.c	重写 uv 配置读写与 get/set/reset；支持 pyproject.toml；新增 python-install-mirror 处理与内部镜像测速 target
src/recipe/lang/Python/uv-helper.c	新增受限 TOML 字符串读写/改写模块（供 uv.c 与测试复用）
src/recipe/lang/Python/common.h	PyPI 源列表行对齐/格式微调
src/chsrc-main.c	更新 contributor 注册信息（邮箱）
Makefile	将 uv-helper-test 接入 make test 并纳入 clean
lib/xy.h	更新库头部贡献者联系方式
justfile	增加 uv-helper-test 的构建/运行入口并纳入 test/clean
doc/12-uv换源实现说明.md	新增 uv 换源实现说明文档（配置优先级、reset 策略、实现边界）
doc/10-如何编写recipe.md	更新文档头部贡献者信息，并新增/调整开发准则条目
.vscode/settings.json	增加 clangd 相关设置（禁用）
.gitignore	增加忽略 *.pdb
.github/workflows/PR-test.yml	更新 workflow 文件头部贡献者联系方式

Suppressed comments (1)

doc/10-如何编写recipe.md:120

• 开发准则第 4 条以中文逗号结尾但没有后续内容，属于不完整的文档条目。

[ccmywish]

@Mikachu2333

#359 (comment)

咱们在这里讨论。

python是从3.11版本加入的toml解析功能

我查了下，3.11 是 2022年10月发布的，距今已经有快4年。

典型的先有鸡还是先有蛋的问题了

是的，但是想了想，C语言的 recipe 如果存在大量自定义操作，维护成本太高了。

如果用 PowerShell，又兼顾不了 Linux、macOS 用户。

所以我还是建议直接用 Python 来换源，并提前用C语言检测版本，<3.11 的提示用户手动操作，大于的，就直接帮用户换了。

[Mikachu2333]

是的，但是想了想，C语言的 recipe 如果存在大量自定义操作，维护成本太高了。

这个我同意，C的维护确实太麻烦

所以我还是建议直接用 Python 来换源，并提前用C语言检测版本，<3.11 的提示用户手动操作，大于的，就直接帮用户换了。

但这个我不同意，因为我经常需要帮别人通过uv干净地安装python，或者说在当下，通过uv安装python才是所有「现代化教程」的首选推荐，连python自己也推出了类似uv的 python-install-manger 就为了避免python的版本地狱和依赖问题。

一旦python通过全局安装，种种依赖问题便接踵而至，所以目前比较「现代化」的教程均推荐使用uv等进行python的版本管理，避免直接系统全局安装python及其依赖。

---

我的建议仍然不变，用其他语言写个简单的解析库，编译为lib，chsrc引用。这是维护成本最低的方法了。

如果按照项目readme所说，必须基于c完成，那我就没啥办法了，toml的格式本就多变，再加上c这个啥啥解析库都得手搓的情况（再叠加上LF/CRLF、 UTF-8 BOM等各种杂七杂八的情况），更是地狱级的

uv helper里面一大半都在各种错误处理

[ccmywish]

用其他语言写个简单的解析库，编译为lib，chsrc引用

1. 总体来说，更困难的是写回文件，读本身比写要简单一些，现有的高级语言的库大多数也是读，而缺乏写。但是光实现读，也超出了我们项目的能力。
2. 编译为 lib
   2.1 如果把二进制的 lib 引入项目，不同平台就需要不同的二进制文件
   2.2 如果把 lib 的源代码引入项目，那么编译的时候还需要引入其他语言的编译器，而我们是希望拿了代码只有一个C编译器就能编译的

所以这条路其实是困难重重的

再加上c这个啥啥解析库都得手搓的情况（再叠加上LF/CRLF、 UTF-8 BOM等各种杂七杂八的情况），更是地狱级的

是的，所以我们不要手搓

[ccmywish]

一旦python通过全局安装，种种依赖问题便接踵而至，所以目前比较「现代化」的教程均推荐使用uv等进行python的版本管理，避免直接系统全局安装python及其依赖。

我上述的描述，没有说要全局安装 python，如果系统里一个 python 都没有，或者有 python 但是 <3.11，那就直接提示用户手动换源。

[Mikachu2333]

明白你的意思了，python 3.11以下直接docs提示，>3.11通过python script换源，也行，我没意见

@ccmywish 等等，python3.11自带的toml解析库也不能写入啊，写入还是得自己实现，这工程量区别不大了就……

[Mikachu2333]

1. 总体来说，更困难的是写回文件，读本身比写要简单一些，现有的高级语言的库大多数也是读，而缺乏写。但是光实现读，也超出了我们项目的能力。

当前我只实现了读这两个相关词条，其它一律跳过

2. 编译为 lib
   2.1 如果把二进制的 lib 引入项目，不同平台就需要不同的二进制文件
   2.2 如果把 lib 的源代码引入项目，那么编译的时候还需要引入其他语言的编译器，而我们是希望拿了代码只有一个C编译器就能编译的

确实，这点我没考虑过

是的，所以我们不要手搓

关键在于用Python解析toml刚刚看了看也是极其难用的，只能实现读，与c的数据交互、写配置还是得重新实现。那引入了外部程序却还不能一次性实现，感觉收益有些低了。

我还是倾向于使用纯C解决。
uv.c，只保留接口，让逻辑通畅
底层实现uv-helper.c在本次维护结束以后由于其中不含任何需要更新的内容，可以持久化保存，而无需更改

---

---

尝试写了，但是越写越发现不对劲，问了问ai

如果做如下改动

1. 检查python版本，按python>=311和<311分类
2. 对python3.11+使用python脚本检查这两个镜像是否存在，传递结果给c，再通过c写入配置
3. 对python的低版本直接文字提示
   这会显著降低uv模块的复杂度吗

逐点分析

 ### 1. tomllib 只读不能写 → 复杂度是“搬移”而非“消除”

 uv-helper.c 目前约 790 行，但它的设计已经是刻意简化的：只做行级整行替换/删除/插入，不解析值（文件头部注释明确写着“刻意
 不处理多行字符串、数组/内联表、转义”）。改用它意味着：

 - Python 3.11+ 的 tomllib 只能解析，没有序列化 API；
 - 要写回配置，要么手拼 TOML 字符串（把 C 里那套改写逻辑原样搬回 Python，一行没少），要么用第三方库 tomlkit（违反无依赖
   原则）；
 - 任何“解析→重写”路径都会丢失原文件注释、键顺序、格式——这是行为退化。uv-helper.c 的整行替换正是为了保留这些而设计的。

 ### 2. 版本检测 + 跨进程是新复杂度，不是减复杂度

 - 需要解析 python --version 输出、比较 3.11 边界、处理 python 不存在/只装 py/系统 python 是老版本等分支——这段逻辑本身
   不比 C 的行级改写简单；
 - C 调 Python、捕获 stdout、解析返回结果、处理子进程失败/超时/中文输出编码——一套全新的错误处理面；
 - 低版本分支“直接文字提示”意味着模块维护两条路径（3.11+ 走脚本、<3.11 走提示），调用链更复杂而非更简单。

 ### 3. “检查镜像是否存在”不需要 Python——curl 就能做

 你方案里的核心新需求是“探测两个镜像是否可用再写入”。chsrc 框架已经有完整的 curl 测速能力（pl_uv_github_release 里
 Nju/Ustc/Lzuoss/CnbPython 的 smURL 与 ROUGH/ACCURATE 测速正是干这个的），curl -I HEAD 检查也足够。为“探测一个 URL 可达
 性”引入 Python 运行时是过度工程。

 ### 4. 与项目硬约束冲突

 - 运行时依赖：chsrc 是单二进制分发，除 curl 外无运行时依赖。要求 python3.11+ 直接缩小适用范围（服务器、CI、无 Python
   环境全挂）；
 - 单文件/纯 C：项目刻意用 C11 单文件编译，把核心逻辑挪进嵌入式 Python 脚本是架构倒退；
 - NO UFO：落地 .py 脚本（即使写 tmp）与“工具不在用户目录产生任何文件”原则冲突。

 uv 模块复杂度的真实来源

 它主要复杂在领域固有的部分，换语言解决不了：

 - 同时支持 uv.toml 顶层布局与 pyproject.toml 的 [tool.uv] 布局；
 - default = true index 选择 + 回退第一个；
 - 父表/段缺失时自动创建；
 - 双源语义（PyPI index 与 python-install-mirror）。

 这些在 Python 方案里一个都不会少。

 如果目标是“探测可用镜像再写入”

 更贴合现有架构的做法：

 - 复用框架的 curl 测速/HEAD 探测确定可用源；
 - 保留 uv-helper.c 的行级 TOML 改写；
 - 上一轮已完成的清理（删 wrapper、合并分支、复用 xy_file_read/chsrc_overwrite_file）已经把复杂度降到合理水平。

 综上：不建议做这个改动。

[ccmywish]

tomllib 只读不能写

这样吗？那确实降低了使用 tomllib 的意义。

双源语义（PyPI index 与 python-install-mirror）

这个确实是固有难点，现在的这个PR解决了这点吗？如果没解决，合并后我来考虑解决。

[Mikachu2333]

双源语义（PyPI index 与 python-install-mirror）

这个确实是固有难点，现在的这个PR解决了这点吗？如果没解决，合并后我来考虑解决。

我认为可视为解决，详情如下。如果要求用户手动输入python mirror也正确响应，那就得靠你多费心了，这个我真写不明白，现在这个已经燃尽了

现在支持传入 chsrc set uv xxx

1. 若xxx仅存在于pypi，pypi自动换源+python测速换源
2. 若xxx仅存在于python，python自动换源+pypi测速换源
3. 若同时存在，自动换源两个
4. 若同时不存在，抛出错误
5. 用户手动输入：当前默认仅修改pypi，python mirror不支持手动指定

来自pr introduction