支持从远程站点获取列表并对配置文件指定条目试运行以提升本地测试体验

[LadderOperator]

对于某些镜像站支持外部贡献更新genisolist的情况，贡献者往往没有镜像站服务器的权限，无法本地运行脚本来测试配置是否正确。且即便是有服务器权限，完全运行完毕检查配置正确性也会消耗大量时间。因此，我建议增加一个指定条目试运行（类似于dry-run）功能，并支持从远程站点获取文件列表并用于配置测试。

其实现思路是：

1. 利用rsync对指定的几个下载配置条目的对应位置，可选地从远程镜像站点或本地文件系统获取文件列表
2. 直接对这些列表处理形成json
3. 此功能集成至genisolist.py内，以参数可选执行。

例如，当某镜像some.mirror.site的贡献者增加多个条目AA、BB、CC之后，他可以通过python genisolist.py -R some.mirror.site -T AA BB CC 从远端测试AA、BB、CC的条目试运行结果。

我们之前实现过这一功能，谨供参考：https://git.nju.edu.cn/nju-lug/NJU-Mirror-Configs/-/blob/main/scripts/genisolist/genisolist.py

usage: Mira download list generator [-h] [-d DIR] [-R REMOTE] [-T [TEST ...]]

Generate download list for Mira

options:
  -h, --help            show this help message and exit
  -d DIR, --dir DIR     Override root directory.
  -R REMOTE, --Remote REMOTE
                        [Remote Mode] Using rsync to get file list instead of reading from local filesystem. Need the base of
                        target site, for example, `mirror.nju.edu.cn`.
  -T [TEST ...], --Test [TEST ...]
                        Test specified `distro`s (multiple arguments input is supported) in INI. If Remote Mode is on, `distro`s   
                        must be specified to avoid heavy rsync job.
  -D, --Debug           Show log in debug level.

[Harry-Chen]

参见 https://github.com/mirrorz-org/genisolist/blob/main/utils/rsync-stub-generator.py

[taoky]

README.md

对于本地测试，可以使用 utils/rsync-stub-generator.py 从镜像站获取文件，并在本地生成一致的目录结构。

---

此功能集成至genisolist.py内，以参数可选执行。

原先 TUNA 版本的 genisolist.py 也是将 rsync 支持写在了 genisolist.py 里面，但是从我的角度看，恰恰不应该这么做：rsync 和其他的部分应该解耦，否则会带来不必要的困惑，例如 tuna/mirror-web#425 所述：

python脚本有一定复杂性且涉及到rsync等与添加配置关系不大的细节，自行分析可能出现理解偏差

[Harry-Chen]

关于此前版本的脚本还有个问题，每次测试都需要从 rsync 拉一遍服务器的文件列表。考虑到写一次配置可能需要若干次测试，这样也造成了不必要的 IO 压力，所以把获取文件列表和生成 isoinfo 分离可能是更好的选择

[LadderOperator]

参见 https://github.com/mirrorz-org/genisolist/blob/main/utils/rsync-stub-generator.py

这文件我先前看到了，分离也合理，没有问题。我理解这个做法相当于是同步和测试分开，同步一些占位文件在本地来直接测试，这其实是我之前考虑的方案😂但是后来没有这么采用，是从使用者角度考虑觉得这样不方便。

这个最开始初衷是为了让更多非镜像站成员参与进来也方便调试，并且尽量减少对本地的影响，比如，我作为一个萌新，本地没有这些东西，也不希望为了这个在本地同步一大堆文件（即便只是stub）在本地，

或者说，从我的角度看，我更希望能简化一下这个脚本的使用方式。毕竟也有条目有多个location，指定path有点太麻烦了，本地的目录应该从我定义的这些条目本身出发去获取最为自然，而不是我去找这个链接，这个不太方便。

也许可以折中一下，只在genisolist上加一个可选的条目测试，只输出指定几个条目的结果不用存成文件也可以。

[LadderOperator]

关于此前版本的脚本还有个问题，每次测试都需要从 rsync 拉一遍服务器的文件列表。考虑到写一次配置可能需要若干次测试，这样也造成了不必要的 IO 压力，所以把获取文件列表和生成 isoinfo 分离可能是更好的选择

这个我同意，这个问题我一开始觉得问题不大主要是因为我们实际应用中新增条目一般都很小。对于有些巨量的条目这确实是个问题

[Harry-Chen]

这个最开始初衷是为了让更多非镜像站成员参与进来也方便调试，并且尽量减少对本地的影响，比如，我作为一个萌新，本地没有这些东西，也不希望为了这个在本地同步一大堆文件（即便只是stub）在本地，

如果是为了测试，可以放在 tmpfs 下面，几乎不会影响本地。

或者说，从我的角度看，我更希望能简化一下这个脚本的使用方式。毕竟也有条目有多个location，指定path有点太麻烦了，本地的目录应该从我定义的这些条目本身出发去获取最为自然，而不是我去找这个链接，这个不太方便。

如果只是测试少量的条目，获取路径的成本并不是很高。如果让 rsync-stub-generator 能够读取 ini 文件获得具体要同步的路径，我也不反对。

也许可以折中一下，只在genisolist上加一个可选的条目测试，只输出指定几个条目的结果不用存成文件也可以。

是说运行时支持指定启用的 key 吗？这个功能我没有意见。此外现在本来也是输出到 stdout 的，不重定向就不会进文件。如果要做一些非 JSON 的 pretty-print 之类的功能我也支持，只要保持最小的依赖就好。

[LadderOperator]

如果是为了测试，可以放在 tmpfs 下面，几乎不会影响本地。

（可以认为这个纯属我个人洁癖，大家都觉得无碍那也没啥……）

是说运行时支持指定启用的 key 吗？这个功能我没有意见。

意思是运行genisolist.py时，不对所有的配置文件中的所有distro生成json，只对指定的distro比如刚刚新增的软件输出。

此外现在本来也是输出到 stdout 的，不重定向就不会进文件

是的，我的意思就是指定distro后输出本来就是测试目的看一眼，也不用重定向。

[LadderOperator]

README.md

对于本地测试，可以使用 utils/rsync-stub-generator.py 从镜像站获取文件，并在本地生成一致的目录结构。

此功能集成至genisolist.py内，以参数可选执行。

原先 TUNA 版本的 genisolist.py 也是将 rsync 支持写在了 genisolist.py 里面，但是从我的角度看，恰恰不应该这么做：rsync 和其他的部分应该解耦，否则会带来不必要的困惑，例如 tuna/mirror-web#425 所述：

python脚本有一定复杂性且涉及到rsync等与添加配置关系不大的细节，自行分析可能出现理解偏差

解谜了： tuna/mirror-web@c5e2d04

原来之前 yaoge 搬到这儿来之后，你们觉得需要解耦又改了回去，双向奔赴了属于是😂

[taoky]

我自己测试 #5 的时候的做法是 example.ini 复制了一份 test.ini，然后在 .git/info/exclude 添加了 test.ini，之后修改 test.ini 来 !include 需要的文件。

或许可以把 test.ini 加到 .gitignore 里面，然后 README.md 里面说明一下？