这是一个创建于 351 天前的主题，其中的信息可能已经有所发展或是发生改变。
开源地址： https://github.com/alicewish/MomoTranslator/
打包一次要好几个小时，要确保各种依赖都配置到位、查漏补缺、配全新系统搞测试，所以真的很希望是用户就给我去运行源代码，现在 ai 这么强完全可以回答大多数和配置环境有关的问题。
自动翻译部分包含了使用网页版 openaiGPT 的方法，因此现在只保留谷歌翻译一个引擎做测试用，其他都去掉了。
虽然为了避免被用于牟利，开源版在完整功能上删掉了填字步骤，但只要非盈利用途就可以将已完成前面步骤的文件发给我，跑这个步骤，然后我再发回。我知道不适合社恐人，但是单独托管这个步骤的成本太高，开源这个步骤又会导致某些东西竭泽而渔、不择手段对我网暴和人身威胁，只能暂且这样。
 |
103
ipwx 350 天前
@Alicewish 开源项目有范式。几十个 py 文件看得快的原因是，符合大部分开源项目的通用范式。这使得很多写得好的开源项目，介入别人的代码只要看几百行。因为扫一眼目录结构就知道每一个部分在干嘛了。
楼主不熟悉 python 项目的开源范式，所以觉得单文件更友好…… |
|
104
ipwx 350 天前
当然不可否认的是，有些写的烂的开源项目，范式是真的烂。所以文件越多越烂，没法介入。
单文件一万行也不符合大部分开源项目的范式。 |
 |
105
Alicewish OP @ipwx 我给别人的开源项目贡献代码时当然按别人的文件结构来。开源范式的定义哪一条提到了代码必须分成多文件而不能使用万行以上的单文件？给个出处。单文件并不会比多文件有明显的劣势，模块化、有序化，用到的所有第三方依赖库清晰有序一眼可辨，可以快速跳转，可以批量替换，方便测试、方便运行、方便打包，不会循环引用，也绝对不会出现一个类在两个以上的文件里写成好几种样子的情况。要是 Django 框架，那没办法只能按框架文件结构来，要是 Flask 之类的，py 单文件就能写。
|
 |
106
lsk569937453 350 天前
我曹，1w 行代码。。。
|
 |
107
sakura6264 350 天前
单文件 1w 行，上下翻个功能想改滚轮都能滚烂了
相比之下如果一个文件一个功能，那么我找对应功能只需要鼠标点几次就行 这种的项目要么是不想让人用源码，开源了但没完全开，要么就是不会用 import ，学了但没完全学 |
 |
108
Joshuahui 350 天前 via Android
作为小白，我觉得遇到的最烦人的问题就是某些 python 的依赖提示“编译 whl 失败，要安装 visual studio”还有就是自己下载的 whl 还要改文件名才能安装
|
|
109
Alicewish OP @sakura6264 大哥，我用的是 Mac ，本来就没滚轮，再说跳转为什么要用滚的，函数结构都按使用顺序和功能标好了。
|
 |
111
April5 350 天前  1
才发现楼主是 "苹果客服真的需要提升自己的知识水平" 这篇帖子的发帖人。
建议标题改成 "我的开源软件用户真的需要提升自己的知识水平"。[狗头] |
|
112
Alicewish OP @April5 两码事好吧，我现在是又干了苹果客服应该干的活：找到 iPhone 系统 bug 的解决方案；又干了开源软件用户应该干的话：按照 README 配置环境。写了一大堆说明，以及常见问题及解决方案和选用该方案的理由，就为了其他人不用踩我踩的坑，然后还得挨你们当中某些人的嘲讽。然后所有人都觉得我对用户太苛刻了，那你们对我不苛刻吗？我是真的为了自己的一个需求从零基础自学各种有可能用得到的技术，并最终写出作品。
|
|
113
April5 350 天前 1
@Alicewish 你自己为了做这个东西付出了多少对于用户来说真的不需要关心，励志鸡汤实在看得够多了。
你明明已经付出那么多把项目做到了 90%，而且看你回复你都有时间帮用户远程配置环境，这时间完全足够把最后的 10% 的 ci/cd 流程或者 编译会遇到什么问题的 FAQ 补全了（这一点也不苛刻）。 最后，不建议在分享创造下起这么一个标题。 |
|
114
Alicewish OP @April5 我为了实现自己的需求付出多少努力跟鸡汤有嘛关系？我只是觉得某些对我的指责本身就挺行为艺术的。远程检查环境和问题是为了确认用户到底遇到什么情况，而且我远程的用户是愿意自己装 python 的，给的报错截图也表明了至少是看了说明再用的；我吐槽的用户是不打包好就不用甚至都不愿意装下 python 的，或者在已经有打包文件的情况下不按说明书用的。
|
 |
115
xzylzz 349 天前 1
所以你到底是希不希望更多的人能使用你的开源项目？希望你就得解决这个问题，你没办法改变别人，因为你看起来也是个固执的人
|
 |
116
mumbler 349 天前
@Alicewish #81 我也做免费工具，以前也和用户吵，因为他们提出一些无理要求，比如一键下载整个优酷，200 元做个淘宝这种，现在我会先判断用户是不是好用户，如果提出问题是合理的，再难我也会去尝试解决，坏用户就不用理了。
EXE 打包这个需求，任何角度看都是一个合理需求，你遇到的困难是因为你选择的技术栈不合适，python 做产品必然遇到这些问题，并不是用户的错。不能换技术栈，可以为自己做一些自动化工具，骂用户只是满足你的情绪发泄，不解决问题 |
|
117
Alicewish OP @mumbler 我几年前做内测版时已经搞打包了，但是现在有 GPT4 辅助，我基本每天都要更新功能，而且因为用到的库更多，打包的整个流程耗时更长。以前一个月打包一次，一两小时，还能接受，现在哪可能经常性花几个小时打包。旧版的问题新版修了，我当然推荐用户用新版，但最新版只有跑源代码，不可能天天都有打包。我手里准备的自动化流程已经很全了，连 GPT4 网页版自动分段翻译都做了，打包也是半自动的，但是打包不能不测试就发布啊。
|
|
118
mumbler 349 天前
@Alicewish #117 那你的问题根源在意你的更新策略啊，每日发布更新是不必要的，完全可以一周一次，一月一次，除非重大更新才临时打包，项目是你的，你定规矩就行，现在你对自己定的规矩不满意，转嫁给了用户，用户何错之有。
佛教的观点：执着是一切痛苦的根源 |
|
119
sakura6264 348 天前
@Alicewish 别人谁知道你什么功能叫什么名，怎么想改个简单功能还得把你那上万的源码通读一遍？而且别人也不一定用 Mac ，用 Mac 也不一定不用滚轮
所以我说要么不完全开源，要么不会 import |
 |
120
zerofancy 348 天前
@Alicewish 配好 Github Actions 是可以每个 Commit 自动出包，自动发布到 release 的。至于『不测试就发布』的问题其实不大，只要编译通过就传到 Release 中，不能帮你修 bug 的用户说不准可以帮你测试，遇到问题也可以快速修复让他装下一个包。
|
|
121
Alicewish OP @mumbler 不对啊，我几年前发打包版是因为代码闭源开发，后来发开源版原因之一是不想打包了。因为中间慢慢用上了 python3.9 的特性，以至于很长一段时间内 nuitka 旧版的老一套打包流程不能用，现在是把库和 nuitka 版本全部改成最新版以后花了几天重新测试的打包流程。至于更新策略，因为每个人用法不同，跑的图片也不同，有些用户报的错其他用户根本碰不到，所以我不想为单个 bug 的修复重打包，但对报错的用户来说 ta 是需要跑最新版才能用的。
|
|
122
Alicewish OP @sakura6264 我在 Win 下也测试了，触控板和触屏都滚得很快，滚轮也可以调速度。而且文件功能和函数都标了使用顺序和对应的中英文。代码里放了几万字中文注释，这都不能靠搜索找到要改哪里的话，我觉得问题不在我的代码上。
|
|
124
sakura6264 348 天前
@Alicewish 问题是，修改者在通读代码前不知道你的各个函数叫什么名，也不知道你的中文注释写在哪，写的什么，名字都不知道怎么搜？
还扯滚轮速度，你滚轮速度再快快过你阅读速度也是没用，怎么您能一眼看 100 行代码并搜索出这些代码里哪个是你想要的功能？ 说简单点这就是树结构和顺序结构搜索效率的区别，你可以继续杠，杠就是你对。 |
|
125
Alicewish OP @sakura6264 图形界面上每个功能和步骤都有对应的中文名。py 文件内部也标了树状结构。一本带目录的书非要按章节撕下来才能读，我觉得是读者的问题。
|
|
126
zerofancy 347 天前
我昨天试了下配置环境和打包，可以理解 OP 了，Python 打包是真的难。
pyinstaller 打包后无法运行，nuitka 打包是将源码和所有依赖编译到 C 语言然后重新编译，生成的中间文件超过 2GB 。 主要是这个项目里很多重量级的依赖，jieba 、paddle 、pyqt 等。 |
Select Language