Fix GitHub actions

[attilaolah]

Branched off of #780 to try and and work on CI only.

[attilaolah]

This is a draft but I don't see the mark as draft button; so please ignore until CI is failing.

[reneleonhardt]

Upper right: Still in progress? Convert to draft (or just prefix the title with Draft: )

[reneleonhardt]

I would change ubuntu-latest to ubuntu-22.04 and macos-latest to macos-13 (oldest supported versions).
That explains the dylib failures too, macos-latest is arm64 of course, macos-13 is for old Intel computers.

[reneleonhardt]

I could fix the actions after hours at least for a single ubuntu build, but the dependencies haven't been maintained in years, can't compile them even after bumping them gently again and again 😞

[attilaolah]

OK should we try maybe a more radical approach?

• Bump version (minor at least)
• Drop everything from the build matrix, except the most recent version
• Update all dependencies to latest stable
• Assess how much effort would it take to migrate to the latest APIs of libraries this depends on

Then whoever needs an older release could still contribute it, or keep using pre-built packages of the older version.

Today that would mean targeting Python 3.13 (3.14 soon), on Ubuntu 24.04 LTS.

[reneleonhardt]

Frankly I don't know if all this trouble is really worth it, I wasted many hours to get some kind of docker build, I can't even build it locally.
And without maintainers what would be the point of all this hard work?
No one will review it, no one will merge it, no one will release it, no one will support the new release.
wasmer-python belongs to the wasmerio organization, I fear if they continue not maintaining it, every effort will be in vain 😞

The CI is years old and the dependencies are years old, there have been 6 major releases to wasmer in that time.
I tried the original Cargo.lock and couldn't build it in Docker, and every minor or major bump to that complicated dependency tree had different breaking changes, and there are no migration notes for all of this.
Without a working local build (or at least a fast Docker build) I can see no realistic chance to bump all those different dependencies.
The CI is extremely complicated:

• It tries to install Python in exotic ways
• It tries to "validate" Python with a Powershell which I couldn't get to work on nektos/act
• It tries to install LLVM in exotic ways
• It compiles just with cargo instead of downloading a binary (or just using the binary in the official runners)
• It compiles fd-find with cargo instead of using the official find command
• If all of this was even successful after many minutes, it uses an old maturin to build the actual extension, which of course breaks immediately because every little warning like a single deprecation is being elevated to a build error
• Every single thing is x86 only, even macOS and Linux builds, which doubles all that fun on Apple Silicon

If a project values maintainers and contributors, the first thing needed for actual development is a local build script which should be as easy as possible.
CI doesn't come first, developers do.