Ok. I'm being silly, I literally wrote that this won't work here due to the "v6.0.0-nightly" tag.

packaging.version.InvalidVersion: Invalid version: 'v6.0.0-nightly'

If you kindly push a tag called "v6.0.0.dev0" and rerun the wheels action everything should 🤞 be good.
Semver tags like "v6.0.0-alpha" or "v6.0.0-rc.1" also work as expected.

Hi, thanks so much for your PR, especially the great documentation of all issues.
I really tried gettings things to work myself for a day or two, but I ran into so many issues, that I moved on to other topics.

For me it's ok, not to ship the compiled protos.

We will try to retag with an alpha tag. But to my understanding, shouldn't 'v6.0.0-nightly' still be semver compliant?

Hi, thanks so much for your PR, especially the great documentation of all issues. I really tried gettings things to work myself for a day or two, but I ran into so many issues, that I moved on to other topics.

Yup, this took a lot longer than I expected too, but worth it.

We will try to retag with an alpha tag. But to my understanding, shouldn't 'v6.0.0-nightly' still be semver compliant?

Yes, but its not Python version specification compliant.
setuptools-scm uses this regex by default to match PEP440 style versions so for Python its strictly enforced for the version to meet this format ([N!]N(.N)*[{a|b|rc}N][.postN][.devN]). There is another section further down that talks about schemes for developmental release (eg: X.Y.devN)

@KerstinKeller Do you need anything further from me here? Everything is passing green now with the new tag (thank you!) except the cherry picker due to the missing label. If some pytests would lighten the validation load for you all and help get this merged I can do that, no problem.

Sorry I was really busy last week. The PR looks already really good. We wanted to do some lokal tests before merging.
Pytests would totally make sense (we can also help write some), I guess they can also be executed as part of the wheel building process?
Anyways, we really appreciate your contribution, and we will likely merge it later this weeks.

One more quick question: is there a reason that the ubuntu builds are done on Ubuntu 20.04 which is soon going to be deprecated. I think cibuildwheel will execute the actual build in a docker container? Or did I get something wrong here?

One more quick question: is there a reason that the ubuntu builds are done on Ubuntu 20.04 which is soon going to be deprecated. I think cibuildwheel will execute the actual build in a docker container? Or did I get something wrong here?

Correct. cibuildwheel does all build in manylinux docker containers. https://cibuildwheel.pypa.io/en/stable/#how-it-works
Those platforms are chosen because I didn't change them when importing what you had previously done.

Will update to ubuntu-latest and windows-latest as it shouldn't affect anything 😄

Sorry I was really busy last week. The PR looks already really good. We wanted to do some lokal tests before merging. Pytests would totally make sense (we can also help write some), I guess they can also be executed as part of the wheel building process? Anyways, we really appreciate your contribution, and we will likely merge it later this weeks.

No worries. Yes, the tests would run as part of cibuildwheel for every wheel

I tested the whl files for Windows Python 3.9 and Ubuntu 22.04 Python 3.10 and everything worked out of the box. I tested the HelloWorld and HelloWorld Protobuf sample from the documentation. The systems were clean and didn't have eCAL installed.

Hi @DownerCase,

I tried to build the python wheel locally on my PC and realized that I have no idea how to do that. Is there a guide somewhere how that can be done?

There are a few methods but I do

python -m pip install build
python -m build

cibuildwheels can also be run locally if you desire.

https://packaging.python.org/en/latest/tutorials/packaging-projects/#generating-distribution-archives

Thanks, works like a charm!

Currently, we have the following python packages:

• .whl files for Ubuntu amd64 and Windows amd64
• .deb files for Ubuntu amd64 / x86 / arm64 / armhf

I checked whether I can reuse the old scripts to generate the .deb packages and that did not work (as expected). While I wouldn't really mind dropping the amd64 .deb installers as those users can switch to the manylinux pypi packages, I would still like to offer the arm64 users a way to install the python binding.

So, do you by any chance know how to
a) build arm64 whl files with the GH Actions or
b) build .deb packages for this python binding?

In the past I used the following script for generating the deb package:

override_dh_auto_install-arch:
	dh_auto_install --arch

	# Python install.
	set -e; \
	cd _build/python && for python in $(shell py3versions -r); do \
		$$python setup.py install \
			--install-layout=deb --no-compile \
			--root=$(CURDIR)/debian/python3-ecal5; \
	done
	find $(CURDIR)/debian/python3-ecal5 -name 'ecal-*-nspkg.pth' -delete

a) build arm64 whl files with the GH Actions

Yes! cibuildwheel can do it: docs. I'll set that up here too

b) build .deb packages for this python binding?

That is outside of my knowledge. Theoretically that method could work on new enough versions of pip to support the build backend standard. You may need to add the minimal stub setup.py.

Yikes, building arm64 in emulation is really slow.

I had a quick look at your deb situation, doesn't look great. For a start you'd be needing to disable the RPATH/install shenanigans as you'd want to depend on the system library from the main eCAL apt package.
On top you have to figure out how to get Ubuntu 20.04 to use new tools. The system packages on there have no idea about pyproject.toml as the ecosystem was stuck on setuptools and setup.py as the standard for so long... Doesn't seem impossible, just a lot of extra work... (Will be easier in the future when the debian packaging tools have fully caught up)

Hmm. Over an hour to get all green CI ticks is unacceptable. Will rework to only trigger the emulated compilation on releases? IMO, I only need to beat the 37m windows build for daily PR workflows.

Is there a way to have them trigger on releases and on "manual trigger" or something similar? I was also thinking about the same thing.

Is there a way to have them trigger on releases and on "manual trigger" or something similar? I was also thinking about the same thing.

Theoretically I've done just that now 😄 It's set to only do the arm64 wheels on (pre-)releases being published or when the workflow is manually started.
See here for how to manually trigger a workflow: https://docs.github.com/en/actions/using-workflows/manually-running-a-workflow