使用MingW在Windows上运送PyGObject / GTK +应用程序

问题描述

我在Windows上使用带有Python3.7的PyGObject / GTK +，并且担心如何打包我的应用。使用官方的Python生态系统，可以轻松使用冰柜和通风阀。但是，Windows上的PyGObject和GTK +需要运行MingW环境。

I'm using PyGObject/GTK+ with Python3.7 on Windows and is worried about how to package my app. With official Python ecosystem, it's easy to use freezers and venvs. However, the PyGObject and GTK+ on Windows requires the MingW environment to run.

这是否意味着我必须打包整个MingW以及GTK +？
我应该如何冻结该应用程序？

Does this mean that I have to package the entire MingW, along with GTK+?How should I freeze the app?

推荐答案

由于没有人足够在意，我将在这里报告我的发现。截至我撰写本文时，简短的答案是： PyGObject生态系统尚未在Windows上投入商业使用，尽管没有什么阻止您交付功能性应用程序。

Since no one cares soon enough, I'll report my findings here. The short answer, as of the date I write this post, is: The PyGObject eco-system is not commercial-ready on Windows, although nothing stops you from shipping a functional app.

交易突破的是Windows上缺少用于PyGOBject的功能冻结器。因此，您无法真正将其附带开源商业产品（尽管有人可能认为整个Python生态系统并非为此而造）。我尝试过的冰柜：

The deal-breaker is the lack of functional freezers on Windows for PyGOBject. So you can't really ship a closed-source commercial product with it (although one could argue that the entire Python eco-system is not made for that). The freezers that I tried:

1. 官方推荐的目前未随官方推荐的宇宙；即使在从源代码构建PyInstaller之后，冻结的.exe也会因缺少模块而产生投诉。下面是来自hello-world应用程序的崩溃报告。

$ app.exe
[8340] mod is NULL - structTraceback (most recent call last):
  File "C:/Apps/msys64/mingw64/lib/python3.7/struct.py", line 13, in <module>
    from _struct import *
ModuleNotFoundError: No module named '_struct'
[8340] mod is NULL - pyimod02_archiveTraceback (most recent call last):
  File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod02_archive.py", line 28, in <module>
    import struct
ModuleNotFoundError: No module named 'struct'
[8340] mod is NULL - pyimod03_importersTraceback (most recent call last):
  File "C:/Apps/msys64/mingw64/lib/python3.7/site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyimod03_importers.py", line 24, in <module>
    from pyimod02_archive import ArchiveReadError, ZlibArchiveReader
ModuleNotFoundError: No module named 'pyimod02_archive'
Traceback (most recent call last):
  File "site-packages/pyinstaller-3.5-py3.7.egg/PyInstaller/loader/pyiboot01_bootstrap.py", line 15, in <module>
ModuleNotFoundError: No module named 'pyimod03_importers'
[8340] Failed to execute script pyiboot01_bootstrap

1. 是另一个重要的选择，它也不在MingW上生成/安装。无论安装了多少个gcc变体，您最终都会遇到gcc的麻烦。


2. 现在已被废弃。

1. cx_Freeze, another prominent alternative, does not build/install on MingW, either. You end up with gcc woes, no matter how many gcc variants you install.
2. py2exe is now abandonware since Python 3.4.

由于PyGObject应用仍在运行MinGW python，因此并非不可能为Windows发行这样的应用程序。但这意味着您将承受沉重的负担，并找到一种可以自己打包所有东西的方法。更alone论保持整个混乱状态。请注意，如果您的应用程序是跨平台的，则在Mac上该过程将有所不同。根据我的测试，PyInstaller在Mac上可以运行。

Since a PyGObject app still runs with MinGW python, it's not impossible to ship such an app for Windows. But that means you'll go with the big baggage and figure out a way to pack everything yourself. Let alone maintain the whole mess. Mind you that the procedure will be different on Mac if your app is cross-platform. PyInstaller works on Mac according to my test.

提供了有关如何基于PyGObject发行开源软件的示例。不幸的是，直到今天，上游的在<$ c处失败$ c> build.sh 在我的Windows 10上运行：

QuodLibet provides an example of how to ship an open-source software based on PyGObject. Unfortunately, as of today, the upstream's packaging procedure fails at the build.sh run on my Windows 10:

copying data/quodlibet.zsh -> E:\_dev\quodlibet\win_installer\_build_root\mingw64\share\zsh\vendor-completions\_quodlibet
Traceback (most recent call last):
  File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 141, in <module>
    main(sys.argv)
  File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 130, in main
    libs = get_things_to_delete(sys.prefix)
  File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 108, in get_things_to_delete
    for lib in get_dependencies(path):
  File "E:/_dev/quodlibet/win_installer/misc/depcheck.py", line 66, in get_dependencies
    data = data.decode("utf-8")
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 72: invalid start byte

事实证明这很容易解决：区域设置问题在非UTF8 Windows上。
一个简单的补丁将用 locale.getdefaultlocale（）替换 utf-8。之后，构建成功。

This turns out to be an easy fix: locale issue on non-UTF8 Windows.A trivial patch would be replacing "utf-8" with locale.getdefaultlocale(). After that, the build succeeds.

但是，全球发行问题仍然具有挑战性：

However, the global distribution issues remain challenging:

• 膨胀的管道：官方推荐的 msys2 构建系统基本上将整个GNOME Universe和大部分Python Universe拖到您的机器上，尽管您可能已经在Python环境中您的本机Windows。事实证明，很难在所有这些东西中挑选必要的依赖项。


• 构建可执行文件所需的额外C管道。要构建没有冰箱的Windows可执行文件，您必须将您的应用创建为Python程序包（大麻烦），将其安装到msys2-Python站点程序包（另一个setup.py麻烦），然后使用Python C API（不透明的麻烦）。该过程并不透明，尤其是当Python打包系统对工作目录和路径差异敏感时。在没有太多调试信息的情况下，启动可执行文件很容易出错。


• 手动剥离。如上所述，您必须手动选择依赖项，否则您的应用程序将基本上带有整个msys2 / MinGW Universe，对于hello-world应用程序而言，其价值超过100MB。

• Bloated pipeline: The officially recommended msys2 build system basically drags the entire GNOME universe and much of the Python universe to your machine, while you may already have a Python environment on your native Windows. It proves hard to cherry-pick the necessary dependencies among this whole pile of stuff.
• Extra C pipeline required to build the executable. To build a Windows executable without a freezer, you must create your app as a Python package (big hassle), install it to your msys2-Python site-packages (another setup.py hassle), and then build a wrapper C application using the Python C API (opaque hassle). The process is not transparent, especially when Python packaging system is sensitive to working directory and path differences. Launching the executable can easily go wrong without much debug info.
• Manual stripping. As mentioned above, you must manually cherry-pick dependencies or your app would be shipped with basically the entire msys2/MinGW universe that's worth 100MB+ for a hello-world app.

这篇关于使用MingW在Windows上运送PyGObject / GTK +应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！