出于复用的考虑,许多 `dish` 直接使用了 `sources dish` 的源。许多贡献者对 `sources dish` 进行了维护,然而这些维护者的信息没有得到展示。 比如 `PyPI` 这个 `sources dish` 里的维护者信息被掩盖了。
Activity
`ls` 打印 `sources_dish` 并增加嵌套缩进
ccmywish commentedon Sep 1, 2026
如果完全实现
combo嵌套 + 展示sources dish,可能会导致不必要的重复,如下例,可见__internal__sources_only_dish__pypi__被多次展示。ccmywish commentedon Sep 1, 2026
由于
bun并不属于js combo,所以我们完全可以让uv也不属于py combo减少 same source 的重复展示
ccmywish commentedon Sep 5, 2026
减少 same source 的尝试方案引入了
chef_all_sub_dishes_use_same_source_from (this, &some_dish);函数,但是又会遇到新的问题:即,如果一个 dish 本身又是具体 dish,又承担了 sources dish 的责任时,它的维护信息会出现两次:ccmywish commentedon Sep 5, 2026
现在我们尝试引入一种新方案(方案名
GH384-A):以下所有的 dish 都指的是在 combo dish 里的 sub dish 为基础来讨论。
由于每个 dish(下文称之为
self dish),它都可能伴随一个sources dish,但是对于这个sources dish,我们可能缩进展示,可能不缩进展示。如果这个 dish 的 sources dish
那就立刻在 self dish 的下方缩进展示。
否则就在所有 sibling dish 打印完后,并列(不缩进)展示 sources dish
无论如何,只让一个 dish 的维护信息,打印且仅打印唯一一次
ccmywish commentedon Sep 5, 2026
上述方案
GH384-A实现非常困难,我们现在引入方案GH384-B:由于
uv已经从Python combo中拆出来,意味着当前没有任何一个combo是嵌套的,这是该方案的基础,即后续我们引入新的 combo 时,也不允许再嵌套。要注意的是,嵌套的一些基础代码依旧存在,之后也并不会删除!依然利用
all_sub_dishes_use_same_source字段,但是在waiter_handle_List_Info()的时候,我们会额外检测,如果借用的这个 sources dish 本身就是 combo dish 里的 sub dish 之一(对应 JavaScript combo 的npm的情况),就不再打印。实现 `GH384-B`