曾奥然

看我上面的截图，本身就是打钩的。重新 save 过了的。

额，有点搞笑，本身就是打钩的状态。 我重新 save 了一下，界面是不变的，但是我刚才重新运行了 action，现在好了。 https://github.com/microsoft/winget-pkgs/pull/301646

Hi @danny8376 Thank you for reporting the bug! 🤝 And thank you again for pointing out to use `get_ruby_bin_path_for_version()` directly 👍 `rbenv-shell.ps1` indeed adds the system ruby to the top...

> 一个是python下载，一个是pip安装pkg 类似于 `nvm` 换源，需要下载整个 Node.js binary，参考： 因此，`chsrc set uv` 的时候，应同时换两个源： 1. `Python` interpreter 的源 2. `PYPI` 的源

@Mikachu2333 在和你长时间的交往中，我知道你的风格是比较积极、勤勉、偏个性化的表达。但是像 **玩意**、**啰里八嗦** 等这些词，容易让人误会成在施压或发牢骚。 除了编写代码以外，我们重要的目的是**建设一个高度互相协作的换源社区**，人是比代码更重要的，我们不仅在看彼此的代码，也在彼此看对方的话语，话语能传达更多的信息，从这个角度上来说，似乎比代码的效率还高。如果用其他的专业词汇（比如，“复杂度会变高”）、或者 正向积极的词汇，甚至简单地用中性词（比如，“变得困难”），来替换一些较随意或者主观色彩太浓厚的词，我想能起到更好的交流效果。 以下是一些诚恳的建议： 1. 格式清晰一些 > chsrc set python分叉执行chsrc set pip, chsrc set uv,... > uv继续分叉为 chsrc set uv pip, chsrc set uv python 比如这段话很多地方可以打上反引号，中英文之间空一个格，让看到这个问题的人一目了然。 2....

@Mikachu2333 提到的 "前一步的错误可能导致后一步出现更多的问题" 是有道理的 这个问题实际变成了：每一个 follower target 之间有没有依赖关系。 - 如果没有依赖关系，前一个 follower target 的执行失败不应该影响后一个 - 如果后一个依赖前一个，前一个的失败就应该影响后一个 目前使用 `Target Group Mode` 的两个就是 Python 和 JavaScript，都是对包管理器的处理，按理说，每个包管理器都是独立的，没什么直接联系。

> chsrc 关于命令的错误处理不太明白， 之前java的设计是取第二行(maven home:)，现在虽然遍历所有，但是对于找不到是没有做到异常处理的，对于底层命令的异常输出, 似乎没有做到在framework 的处理， 也没有在 具体实现中处理， 期望是， framework 处理 错误的 退出码， 具体实现处理自己的查找不到自己或者其他逻辑。 看 #268 我的回复，实现了 `xy_run_capture()` 直接得到 stdout 的输出，忽视 stderr。

可以直接 git commit 来完成该工作吗？ 1. 构建出 Packages、Packages.gz 文件 2. 进入 https://github.com/RubyMetric/chsrc.run 仓库 3. 把上述相关文件放到 `./apt` 目录 4. `git add apt/Packages apt/Packages.gz ...` 等等相关文件 5. `git commit` 暂时测试条件，触发条件为 push 到 `gh-build`...

> git历史被污染 虽然是在本仓库（RubyMetric/chsrc）中写的 workflow，并在此运行，但是 git commit 到的是 RubyMetric/chsrc.run 这个仓库，所以污染的只是那个仓库，那个仓库本来就用来专门放生成的文件。 不过，我也觉得这种方法很原始，如果有其他方法那就更好了。

这两天我改动有点多，怕和你之后的工作起始点冲突，到时候合并太麻烦，我就先不管了，代码稳定下来。 等你搞定之后（不着急，因为现在用户已经可以直接按照README下载安装 deb 包了），我再接着参与这个 issue。