Open emfox opened 4 years ago
@emfox
If you don't mind reading zh-CN, I could tell you the story.
In short:
There's really no need to build
or install
, and setup.py
does not help to correctly resolve the dependences of mcomix3 (and maybe any python program depends on pygi and gtk3).
For packaging, simply treat anything in mcomix/
as data files, and call mcomix/mcomixstarter.py
with the interpreter.
Yes, please. 中文讲讲,我想听故事 :)
mcomix的gtk3移植不是我写的,是上游的一个PR,但一直没合并。因为mcomix(和当时的gnome-terminator)的py3移植需要面对的问题基本上只有GUI,也就是pygtk到pygi/gtk3的改写,只要这部分搞定接下来的事情就简单多了。 这两个的py3移植我是两年前写的(满足自己的需求,同时也算是写着玩的),几个晚饭后就写得差不多了。当时距离py2结束还远得很,我也不认为上游会轻易隐退,所以两个都尽量做成不与上游文件冲突的形式,也没打算兼容py2,这样测试也方便,debian自己管理包依赖也就没有pypi的事情,py3也没有pygtk这么个东西,上游的setup.py又不兼容py3,所以当时先就在setup.py开头加了个错误退出,免得误导别人。那以后就是跳错了才修一修,用着没出错就行了。 installer.py只是复制文件和执行外部命令生成翻译文件的机器码,没花头的,写成shell或着直接make也可以。
一是我并没有打算取代上游,把脚本都放在独立路径和portable mode就是为了让用户(和开发者,包括我自己)能够在完全不更改已有配置文件的情况下测试和使用,所以就不需要install,mcomix3本身并不是binary所以也不需要setup.py处理abi对应的build,不需要build也不需要install,setup.py就没用了。
二是mcomix本来理论上应该可以在win32运行,因为依赖的模块在pypi上都有预编译的文件,但没有pygi,就算有pygi也没有gtk3的gir。我不清楚gir的初衷,只看现况,这东西把后端库在其他语言的binding全都承接下来了。这个思路不错,解释器只需要一个调用gir的模块,后端库也只要做一个外显到gir的模块,大家就可以一起玩,但是这里同时也有问题:谁来解决依赖。pypi当然只管py这边的模块,不可能把所有后端库的gir全部包括进去(当然现状是连pygi都没有,都要靠系统来提供),gtk3官方也没有win32包,唯一up to date的预编译文件好像只有msys提供,但这也是和linux一样自己管理依赖的环境,所以经由pypi处理依赖的setup.py并不能处理依赖。既然setup.py无法正确完成setup时应当处理的步骤,那么留着它不就是误导了么。
还有就是我想尽量减少mcomix3的必需依赖。GUI库是GUI程序的必需依赖,PIL是图像格式的必需依赖,而setuptools/distutils不是mcomix3本身的必需依赖,那么就不要让setup.py多这么一个依赖了。在debian下如果仅打包mcomix3,应该只要debhelper和python3,生成翻译文件机器码的msgfmt也有单文件的pure py。
好吧,谢谢分享,很复杂曲折啊,那就先保持原状吧。看将来有没有变化,比如官方合并了gtk3之类的
我觉得目前上游合并gtk3的可能性不大。 上游要做win32兼容,而且代码里\n和\r\n混用,估计开发者自己主要用的就是win32。而python官方都说了win32下继续用pygtk,也就是py2/gtk2,gtk自己也没有win32的安装包,合并gtk3就等于是放弃win32了。
不过mcomix用gtk做GUI大概也算是历史原因了,如果是自己写跨平台GUI应该会选pyside或者kivy,不会考虑gtk的。
嗯,好的,看来目前先只能这样。能用就行了,大不了再fork一次另起炉灶,comix到mcomix又不是没干过……
Hello, people! I am studying Meson, and I think I can help putting it in MComix3.
@AndersonTorres That is complete and utter overkill for a python program.
Perhaps you can use conda
? It installs gtk3 with this simple command conda install -c conda-forge gtk3
, and it's crossplatform.
I'm not really sure how having the user install a package manager to install a single package is a good alternative to having a make install
or setup.py install
or other build script. And if we wanted the overhead of a package manager, why not pip, since more people already have that?
In any case, requiring conda might be especially annoying for windows users (I am not one of those, but I did use comix/mcomix on my last win32 machine quite regularly).
Hello, as debian is fast pushing the python2 removal work, I have updated mcomix debian package from official to this port. During the packaging, I just found and wonder why we switch away from setuptools(or distutils) to hand make installer.py? I tested the old setup.py, the main problem is the move of directory mcomix to subdir mcomix/mcomix. Or is there anthing I haven't noticed? If possible, could we get back to setup.py, which is more friendly to enduser, especially distro packagers?