增加uv的python下载镜像

[Mikachu2333]

1. 增加uv的python下载镜像
2. 现在uv会同时对pypi和python进行换源
3. uv支持rest
4. uv换源和reset时响应 -scope

问题描述

1. uv无法对python下载进行换源
2. close uv 换源不完整，还需考虑 Python 解释器本身下载地址的换源 #309 uv 换源不完整，还需考虑 Python 解释器本身下载地址的换源 #358

方案与实现

1. 实现对 ~/.config/uv/uv.toml 中配置的改写，相关参考已写在代码内。

[github-actions]

Hi @Mikachu2333,

❤️ 感谢你的贡献！你的 PR 当前基于 main 分支，请修改使用 dev 分支

[github-actions]

Hi @Mikachu2333,

❤️ 感谢你的贡献！你的 PR 当前基于 main 分支，请修改使用 dev 分支

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the Python uv recipe to support additional metadata and to configure both PyPI index sources and Python interpreter download mirrors via uv.toml.

Changes:

• Updated recipe metadata (last-updated dates, sauciers).
• Improved getsrc behavior with better missing-config handling and printing python-install-mirror when present.
• Refactored setsrc to write both [[index]] and python-install-mirror, adding multiple GitHub Release mirror candidates for auto-selection.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 8 comments.

[Mikachu2333]

@ccmywish READY.

[Mikachu2333]

另，由于我的配置文件没有其他设置，所以我没有对复杂场景的edge case做过多考虑。遇到了再说

[ccmywish]

所有的 free() 都不要，recipe 里全部不用 free

只考虑 xy.h 和 core.c 去 free()

[Mikachu2333]

@ccmywish 正在修改。主要想问一下能不能给GitHub的copilot设置一下prompt，让它别挑每个配方的内存泄漏的问题……我就是因为一开始GPT疯狂提示泄露才改的

[ccmywish]

@Mikachu2333

这里的 Copilot 留下的只是评论，可以完全忽视。

能不能给GitHub的copilot设置一下prompt

https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review#customizing-copilots-reviews-with-custom-instructions

我们有这个文件，但是似乎这里的 Copilot 没读，可能要加一句 When performing a code review, ...，你可以顺便改一下

[Mikachu2333]

所有的 free() 都不要，recipe 里全部不用 free
只考虑 xy.h 和 core.c 去 free()

关于这里，我在想是否应该这么表述

如contributors自行在pr中考虑了其贡献的recipe的内存泄露与回收问题更佳，不考虑回收也不要紧，项目组仅关注对 xy.h 和 core.h 中的内存泄露问题。

另，如果你同意我的表述，上述要求应该写在doc中的代码贡献部分才是。要是你坚持recipe中所有内存泄漏一刀切不考虑我就改回去。不过无论怎样代码风格提示文件里面都应该写明

[ccmywish]

如contributors自行在pr中考虑了其贡献的recipe的内存泄露与回收问题更佳，不考虑回收也不要紧，项目组仅关注对 xy.h 和 core.h 中的内存泄露问题。

其实理论就应该按照你说的这样。但是我希望 recipe 里一个 free() 都没有出于这样的考虑:

1. recipe 本质上是用C语言实现的 DSL，应该高度精炼简化，避免一切和该 recipe 不相关的内容，包括各种文件操作，包括这种语言自身的问题。这也方便其他贡献者快速看 recipe 本身的逻辑，不被任何其他内容干扰。

2. core.c 实现了大部分处理，所有对资源的处理（包括文件操作、内存、子进程调用）都需要在这里完成，所以这里处理内存（当做是一种资源）是合适的

3. 其实不 free 你的程序大概率不会崩溃，但是一旦 free 就可能出现 double free, use after free 等问题，造成更多可能的崩溃

4. chsrc 需要降低贡献门槛，有一个目标就是让不懂C语言的用户能在AI帮助下自己编写 recipe，直接用 core.c 和 chef.c 实现的 DSL 就行了，其他应该完全不在乎。如果其他 recipe 里有 free()，这些人可能照猫画虎也添加 free()

综上，在我们是一个命令行程序无需管理内存的大前提下，不如一刀切不要在 recipe 里 free，你可以在文档里简要说一下这些。