new setup.py?

[emfox]

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?

[multiSnow]

@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.

[emfox]

Yes, please.
中文讲讲，我想听故事 :)

[multiSnow]

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。

[emfox]

好吧，谢谢分享，很复杂曲折啊，那就先保持原状吧。看将来有没有变化，比如官方合并了gtk3之类的

[multiSnow]

我觉得目前上游合并gtk3的可能性不大。
上游要做win32兼容，而且代码里\n和\r\n混用，估计开发者自己主要用的就是win32。而python官方都说了win32下继续用pygtk，也就是py2/gtk2，gtk自己也没有win32的安装包，合并gtk3就等于是放弃win32了。

不过mcomix用gtk做GUI大概也算是历史原因了，如果是自己写跨平台GUI应该会选pyside或者kivy，不会考虑gtk的。

[emfox]

嗯，好的，看来目前先只能这样。能用就行了，大不了再fork一次另起炉灶，comix到mcomix又不是没干过……

[AndersonTorres]

Hello, people! I am studying Meson, and I think I can help putting it in MComix3.

[wyatt8740]

@AndersonTorres That is complete and utter overkill for a python program.

[NightMachinery]

Perhaps you can use conda? It installs gtk3 with this simple command conda install -c conda-forge gtk3, and it's crossplatform.

[wyatt8740]

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).