@huzhizhao ipfs 客户端

loguru

@Mithril 这里的情况是扩展直接调用了主程序提供的 API 操作程序行为，所以不是那种主程序只调用扩展提供的函数的情况。

我觉得按照前面 @secondwtq 提到的，弄个自己做的专有素材就能绕过 GPL 了。毕竟你代码总不能传染到我的画上面吧，缺了我的美术素材你的程序又跑不通顺

看了一眼插件和插件加载方式，按我对 GPL 的理解，插件是要被传染的。

所以针对你问题的答案：

1. 在这个情况下是的。
2. 前提是你的 js 不能经过混淆，压缩或打包。
3. 无禁止转载的权力，有收费的权力，但是无禁止别人收费的权力。同时售卖者有义务在购买扩展的用户索取的时候免费提供源码。

@Mithril 看了一下，这个游戏的扩展调用了主程序提供的 API 。

再买一套房找回生活乐趣

Semaphore

反正游戏本身是 GPL 开源的，你不如直接说游戏名字我们看看他的插件到底是怎么加载的。。。

矩阵运算不满足乘法交换律

性能差距其实还是有的，`re.findall('', '')`的情况下在函数内 import 就会慢个 15%左右。

除非是 cli 程序，第二种写法能减少 python 需要加载的模块数，否则想不出这么做的理由

第二种写法不累吗？

不知道 cf worker 啥样，单说 gh action

secrets 的设计就不是在“坏人成功登录了我的账号”这个前提下工作的...

首先 PR 的 workflow run 是读不到你 repo 的 secrets ，能读到 secrets 的 workflow 必需在你仓库里。也就是说要么是你合并了别人的 PR ，要么是其他有写权限的人提交到你的仓库里。

一个简单地而例子，你的 actions 要推 docker 镜像到 docker hub ，你总不能把 docker hub 的 token 明文写在 workflow 里面吧。

这种时候用 secrets ，只要你自己不加 echo 语句，upload-artifact 之类的骚操作，不把泄漏 secrets 的 PR 合并进你的仓库，不给你不信任的人 write 权限，你的 docker hub token 就不会泄漏。

docker ，还能顺便避免依赖问题

@renfei 当然会丢。需要有节点 pin 住你的文件，相当于 bt 网络里有人固定做种。整个网络里没人做种了，文件又在所有的客户端都缓存失效的时候就丢了

@LeslieLeung 也不是，这几天的几次 GitHub 崩溃是从 git 和 GitHub API 开始的…

有些包 conda 有预编译的 wheel ，pip 没有，用 conda 安装不需要自己解决编译问题。

好像是中间有一次单节点的部属方式被废弃了