Packaging on OBS (for Tumbleweed)

[s-m-e]

Reported by @jayvdb in #55 although not related.

This is probably the cause of my rpm %check failures at https://build.opensuse.org/package/show/home:jayvdb:py-bridge/python-zugbruecke

If we can get this solved, I can run zugbruecke tests on the openSUSE test grid, which includes arms, ppc, etc, which addresses some of your other outstanding issues.

The Tumbleweed builds fail because ... well, have a look at this project's travis file, sections install and script (the actual test). There are two things missing in your spec file.

1. For a test to work, a test DLL file is required. It is built by running make dll from project root. The test therefore requires a cross-compiler (mingw). The DLL is not part of the distributed Python package, however.
2. In its current form, as part of make install, I run wine-pytest --version. The trick here is that this script pulls in CPython for Windows, pip and pytest (in case something is missing). It is not necessary to do this but doing it like this prohibits the kind of timeout that you see on OBS when running pytest later on.

Bug #55 already refers to a much cleaner solution that substitutes wine-pytest (and some other stuff). It's a new Python script named wenv. Have a look at the unpublished (but implemented) changes for 0.1.0 in the change log of the develop branch. Actually, wenv is kind of a topic on its own - I am currently separating it from zugbruecke into its own Python package.

[jayvdb]

Just some quick responses.

I've been building up a openSUSE collection of wine-python3 https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37 , and normal packages https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages-p2 , and even a Nuitka package set https://build.opensuse.org/project/show/home:jayvdb:wine-python3:py37:packages-Nuitka

It is automated using some overrides to python-rpm-macros at https://build.opensuse.org/projects/home:jayvdb:wine-python3:py37:packages/prjconf

I would rather be using that instead of wenv, as usually virtualenv-ish things are hard to control on OBS - it already provides a isolated VM, and the VM is readonly except for the buildroot, and the PYTHONPATH needs to be system + buildroot, and virtualenvs typically bungle that up / create a new set of side-effects.

That said, I'll start getting wenv packaged at https://build.opensuse.org/package/show/home:jayvdb:py-bridge/python-wenv

I see in zugbruecke/core/wineenv.py that I only need a pre-existing python.exe , so I think I can provide that.

https://build.opensuse.org/package/show/home:jayvdb:wine-python3:py37/mingw-w64-python3-base is the relevant project - and it has a project link at alternative name https://build.opensuse.org/package/show/home:jayvdb:wine-python3:py37/mingw-w64-python3 . This 'python3' / 'python3-base' is the same structure as the 'real' linux packages @ https://build.opensuse.org/project/show/devel:languages:python:Factory . There are only minor changes to those spec files. My wine project builds are disabled atm, as I wanted to take pressure of the OBS farm as I wasnt using / continuing that project atm. I'll get it operational again.

Also as you probably know, the embedded CPython redists are a dogs breakfast, especially Windows. It lacks venv support, and many other things, so the external virtualenv also doesnt work. I would strongly recommend that you look into using the Windows images from https://github.com/indygreg/python-build-standalone, but indygreg/python-build-standalone#19 and indygreg/python-build-standalone#22 would need to be solved first. But once they are done, you'll no longer be at the mercy of the MSI installer vs Embedded zip problem, as the python-build-standalone project wants to be a meta-distribution that contains everything and provide the downstream with metadata so they can pick and choose which bits they need.

[s-m-e]

The embedded CPython redists ... yes, they are not ideal. But they work fine on Wine. I can not say this about most contemporary alternatives. This was (and still is) the selling point for me. For a longer version of the story see here. I have been working around this problem for about six or seven years now. Bottom line: I need a very robust (and simple) solution for running Python on Wine for zugbruecke and other things (example, example).

as usually virtualenv-ish things

Hmm wenv is not that virtualenv-ish. It's basically the embedded CPython redist, unpacked, with an added site-packages folder, a shared folder and some tweaks to its config so it finds packages in the right places (site config). In its current form it resides in {sys.prefix}/shared. It more or less behaves like a virtual environment, but it really is not one. It's much less.

I see in zugbruecke/core/wineenv.py that I only need a pre-existing python.exe , so I think I can provide that.

That's awesome. If I understand your OBS space, the spec files and patches correctly, you're cross-compiling Python for Windows/Wine on Linux (OBS) with mingw? Impressive. I did not dare to do this, but the thought had crossed my mind ...

I would strongly recommend that you look into using the Windows images [...]

Nice. Thanks, I'll keep an eye on them.

That said, I'll start getting wenv packaged

Again thanks for this. I just pushed the first release of wenv up to pypi. In case you want to use it. I'll soon remove this code from zugbruecke.

If I may ask: What's the overall goal of your efforts?

[jayvdb]

you're cross-compiling Python for Windows/Wine on Linux (OBS) with mingw?

Yup. The credit goes to the people involved in https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-python3 , inc the Anaconda team.

What's the overall goal of your efforts?

None. I chanced upon your repo, and thought it was interesting, and saw the overlap with what I had been working on. The goal of my previous work was to build standalone Windows exe's from Python code, and do that build on Linux esp OBS where deps can be pre-built and are managed as discrete units. Previously I was focused on Nuitka, which is a very good solution, however atm I am focusing on PyOxidizer. Oddly enough, my rough objective/motivator was to be able to build a Jupyter exe with common kernels/plugins pre-built, removing the complexity in user's getting a useful Jupyter environment locally.

[s-m-e]

@jayvdb Not published on PyPI yet (too many rough edges and an odd setup process), but it now does more or less what it is supposed to do: wenv-kernel, a Jupyter kernel for Python on Wine.

[jayvdb]

Not related - just a note, https://github.com/uranusjr/pythonup-windows and https://github.com/uranusjr/pythonup-posix , and predecessor https://github.com/uranusjr/snafu may be of interest.