重构构建流程并添加新功能

[Loyalsoldier]

随着本项目的成长和影响力的扩大，在过去一年左右的时间里，本项目出现了几个问题：

• @cn 属性的存在，导致 geolocation-!cn 类别里出现了很多“大陆域名”（隶属于非大陆企业，但在大陆有接入点的域名）
• 每个列表的域名规则无法去重（如 geolocation-!cn 包含大量顶级域，可以通过树去重，以减少生成文件的体积）

现在此提议，在构建流程中引入多种选项和特性：

• 自动按优先级查找 data 文件夹的位置（命令行选项）
• 可自定义生成文件的输出目录（命令行选项）
• 可自定义用哪个列表来生成 gfwlist.txt 文件（命令行选项。geolocation-cn 或者 cn 即为白名单，geolocation-!cn 即为黑名单）
• 可自定义去除带有特定属性的规则（命令行选项）：生成文件时，去除带有某些特定属性的规则，如：geolocation-!cn 列表去除 @cn 属性的规则；geolocation-cn 列表去除 @!cn 属性的规则（目前并无此规则，但后续可以考虑加入此类域名到 geolocation-cn 列表）
• 扩展 include 语法：支持 include:filename@attribute（由此，geolocation-cn 可以 include:google@cn；geolocation-!cn 可以 include:alibaba@!cn）

⚠️ 注意：规则去重功能只处理不带属性的 Domain 类型的规则。

[kslr]

3. gfwlist 作为一个临时解决方案，不应该继续扩大影响力，这种方案应该逐渐被移除；
4. 这会改变集合的定义，如果移除，那为什么不用一个新的诸如 geopop 这样的名字；

[Loyalsoldier]

3. gfwlist 作为一个临时解决方案，不应该继续扩大影响力，这种方案应该逐渐被移除；
4. 这会改变集合的定义，如果移除，那为什么不用一个新的诸如 geopop 这样的名字；

第四点没看懂什么意思

[kslr]

比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗

[IceCodeNew]

比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗

附议。

[Robot-DaneelOlivaw]

我觉得geolocation-cn、geolocation-!cn的变更可以留到另一个issue，保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受，如果以后用户想要自行构建geosite，应该会用上这些功能。

另外想问一个无关的问题，有办法在配置文件中指定DLC中的所有列表吗？例如geosite:all这种特殊值？

[Loyalsoldier]

比如 geolocation-cn 就是一个集合的定义，如果允许修剪类型不就破坏掉这个概念了吗

这就涉及到怎么理解 geolocation-!cn 的定义了，你可以理解为公司注册地是海外，也可以理解为域名接入点在海外。对于用户而言，好用才是第一位，意味着按用户直觉，geolocation-!cn 生成的列表就不应该出现接入点在大陆的域名。所以，我觉得引入这个功能是有必要的。

另外，结合这个新的 include 语法：

• 在 cn 列表里 include:geolocation-!cn@cn
• 在 geolocation-!cn 列表里 include:geolocation-cn@!cn

就可以实现 @cn 和 @!cn 属性规则乾坤大挪移的效果，一切的不合理就回到了直觉该有的模样，而且不需要新增诸如 google-cn 这样奇怪且多余的列表。

另外，geolocation-!cn、geolocation-cn 和 cn 三个生成的列表里，也不需要出现带有 @ads 属性的规则，纯粹浪费空间，可以在生成时一并去除。

[kslr]

关于第一点，可以回到这个问题 #28

[Loyalsoldier]

如果觉得「在生成列表时去除带有某些属性的规则」的功能违反之前的共识，本项目可以默认不开启这个功能。把功能开启的选择权留给有需要的用户或项目（例如 shadowsocks-windows）

[kslr]

目前在用的有 ss-win 和trojan-go ，都是通过pb引入，所以我觉得从生成器入手可能也不行

[Loyalsoldier]

目前在用的有 ss-win 和trojan-go ，都是通过pb引入，所以我觉得从生成器入手可能也不行

项目都是读取的 dlc.dat 文件啊，在生成 dlc.dat 文件的阶段就不加入被剔除的规则到 dlc.dat 文件里不就好了吗

[kslr]

如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据，我觉得这会给未来带来很大的麻烦。

这个问题要回到之前 SS 的 ISSUE 上

[Loyalsoldier]

如果将影响限制在手动生成需要的文件时可以接受。
但如果他们不再是从latest获得而是自行生成数据，我觉得这会给未来带来很大的麻烦。

这个问题要回到之前 SS 的 ISSUE 上

有几个选择：

1. 我们提供这个功能，默认不开启这个功能
2. 实现 1，且再生成一份 geolocation-!cn 列表无 @cn 规则的 dlc.dat（说明区别）
3. 实现 1，且 Shadowsocks 项目组开一个新仓库，基于这里的 data 文件夹，定期发布他们自定义构建的 dlc.dat。其余想自定义 dlc.dat 的用户或项目，也可以这么操作。

[kslr]

cc @studentmain

[database64128]

Since 4.3.0.0, shadowsocks-windows defaults to direct connection for domains in geosite:cn and geosite:geolocation-!cn@cn in PAC mode.

More details: shadowsocks/shadowsocks-windows#2990

[Loyalsoldier]

我觉得geolocation-cn、geolocation-!cn的变更可以留到另一个issue，保留现状、修改定义、新增列表都可以。就构建流程而言这些新增功能可以接受，如果以后用户想要自行构建geosite，应该会用上这些功能。

另外想问一个无关的问题，有办法在配置文件中指定DLC中的所有列表吗？例如geosite:all这种特殊值？

geosite:all 当然是可以实现的，只是生成的文件会大一倍。其实只要在路由设置里直接设置全部代理或者全部直连，不就相当于 all 了吗？为何需要这个 geosite:all，有什么具体的应用场景吗？

[IceCodeNew]

我觉得这边的讨论有些陷入停滞了，目前 #255 还没有人审核过，我觉得现在主要影响进展的问题有两点：

1. attr 被视为一个实验性的功能，但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
2. 我们不太愿意改变之前对诸如 geolocation-cn 这些域名分类的定义
   但是总的来说，这些都不妨碍 Refactor the build process & add some features #255 得到推进，从 PR 的主要因素来说，这个 PR 主要做的就是构建流程的改进，而这些改进在我看来都很实用且必要。

我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR，这样我们可以绕开很早就有且一直难以得到定论的问题，先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的，但我猜想它可能并不是非得和其他改进一同实现不可。同样的，「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。

因为我参与不深，所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进，但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进，加入提取带属性域名的功能，但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目，根据自己的需要改变诸如 cn 文件的内容，来得到自己需要的域名列表。

[Loyalsoldier]

我觉得这边的讨论有些陷入停滞了，目前 #255 还没有人审核过，我觉得现在主要影响进展的问题有两点：

1. attr 被视为一个实验性的功能，但很多使用到本项目数据的第三方项目都在 push 本项目使用 attr 属性
2. 我们不太愿意改变之前对诸如 geolocation-cn 这些域名分类的定义
   但是总的来说，这些都不妨碍 Refactor the build process & add some features #255 得到推进，从 PR 的主要因素来说，这个 PR 主要做的就是构建流程的改进，而这些改进在我看来都很实用且必要。

我希望 @Loyalsoldier 可以确认一下 #255 是否能够拆分成几个小的 PR，这样我们可以绕开很早就有且一直难以得到定论的问题，先把相关的功能实现起来。
比如 #255 对 geosite:cn 的改变我个人是支持的，但我猜想它可能并不是非得和其他改进一同实现不可。同样的，「在生成列表时去除带有某些属性的规则」的功能也可以放在别的 PR 里。

因为我参与不深，所以可能做这样的总结很不合适。但我确实感觉到 #255 虽然是被 ss-win push 来的改进，但我们这个项目本身不是为 ss-win 服务的。我们只需要先推进在构建流程上的改进，加入提取带属性域名的功能，但不一定需要改变本项目 release branch 得到的域名列表。
其他项目可以根据自己的需要 fork 这个项目，根据自己的需要改变诸如 cn 文件的内容，来得到自己需要的域名列表。

总体而已，该 PR 的目的是让构建流程扁平化，顺便扩展了 include 的语法，并引入了去除带属性规则的功能。不使用就不打开即可。如果命令行选项不打开，就跟现有的输出没有本质区别，只是规则的顺序不同而已（事实上，目前命令行选项默认没有打开）。

[Loyalsoldier]

另外，我在自己的 repo 使用了这个 PR 的代码，默认开启了去除属性规则的功能：https://github.com/Loyalsoldier/domain-list-custom

可以看看效果

[akiirui]

#259 我也正打算整理DLC， 然后发现你写了支持 include:filename@attr 的代码。

使用 include:filename@attr 并且规范化列表可以解决上述所有问题。

[Loyalsoldier]

#259 我也正打算整理DLC， 然后发现你写了支持 include:filename@attr 的代码。

使用 include:filename@attr 并且规范化列表可以解决上述所有问题。

其实大部分只有一两个域名的列表是我引入的，当时也没考虑太多。但是现在列表多了之后，反而导致了生成文件的无谓增大；以及 data 目录超过 1000 个条目，无法全部看到。

如果需要纠正这个问题，其实有两个方向：

• 在 data 目录中移除只有一两个域名的列表，并整合到大的分类中
• 在构建阶段，提供一个命令行选项，可以删除「只有给定数量的规则」的列表以减少生成文件的体积

以上两个方案的前提是解决这个问题：v2fly/v2ray-core#237

[Loyalsoldier]

其实如果不想改变之前对 geolocation 相关列表的「定义、意义和作用」达成的共识，可以新增一个叫 not-cn 的列表，对标 cn 列表，内容为:

include:tld-!cn
include:geolocation-!cn
include:geolocation-cn@!cn

同时，cn 列表修改为:

include:tld-cn
include:geolocation-cn
include:geolocation-!cn@cn

这样就可以绕过 geolocation 这个单词的含义了。只不过又让生成文件臃肿了许多。

[Loyalsoldier]

至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

只不过这个方案需要下游和第三方软件也同时支持 v5 的路由系统，才能使用新的 geosite.dat（当然，另一个妥协方案是同时生成展开版的 geosite.dat 和非展开版的 geosite.dat）

[Loyalsoldier]

无论最终采用哪个方案，#255 里的新构建流程都是可以支持的，因为做到了尽可能的功能解耦。

[kslr]

现在已经陷入了困境，请 @Robot-DaneelOlivaw 也参与下。

[Robot-DaneelOlivaw]

抱歉，事务繁忙，没办法及时跟进。

哪怕不更改列表定义，#255 引入的功能也是很实用的，我觉得并没有什么问题，是需要一个人来拍板吗？

至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

考虑到许多用户在空间紧张的设备上使用，geosite文件能瘦身当然是最好的，不知道性能会不会受到影响？

另外像 v2fly/v2ray-core#237 提到的那样，如果配置文件中有不存在的列表，提示错误后依然能正常启动，那DLC删除/移动列表会少很多束缚。

[kslr]

抱歉，事务繁忙，没办法及时跟进。

哪怕不更改列表定义，#255 引入的功能也是很实用的，我觉得并没有什么问题，是需要一个人来拍板吗？

至于解决生成文件臃肿的问题，有一个方案：趁着 V2Ray 准备发 v5 版的东风，改造 v2ray 的路由系统，以便支持 geosite.dat 内的列表内嵌结构。意为，不需要把每个列表都拍平（不需要展开 include 的规则），直接 include 即可，而是在 V2Ray 解析配置文件时再动态解析 include 的列表。geosite.dat 就可以瘦身许多。

考虑到许多用户在空间紧张的设备上使用，geosite文件能瘦身当然是最好的，不知道性能会不会受到影响？

另外像 v2fly/v2ray-core#237 提到的那样，如果配置文件中有不存在的列表，提示错误后依然能正常启动，那DLC删除/移动列表会少很多束缚。

geosite 现在压缩后只有 80~200kb 我觉得问题并不大吧
第二个问题可以解决掉，改成错误但不崩溃（但不清楚是否需要这么做）

的确需要人来拍板，这个项目我并不熟悉，需要你们来决定