Should the "32-bit" Windows builds and Linux AppImages be dropped?

[bastimeyer]

Asking this on the main repo for the sake of visiblity... Since it affects both the Windows builds and Linux AppImages, it doesn't make sense opening an issue on each of the issue trackers of the respective repos.

I could also simply ignore user feedback, but I'm interested to hear about actual use cases.

---

Issue

Both the x86 Windows builds and i686 Linux AppImages are currently stuck on Python 3.11 and can't be upgraded to Python 3.12 due to missing wheels of some of Streamlink's dependencies. This blocks the upgrade of other architectures (x86_64 and aarch64) from Python 3.11 to 3.12, because all builds are supposed to be kept on the same version of Python, to avoid unnecessary maintenance headaches and to avoid unnecessary end-user confusion. New dependency issues have also already come up...

• TODO: Upgrade from Python 3.11 to 3.12 windows-builds#7
• TODO: Upgrade from Python 3.11 to 3.12 and switch from manylinux2014 (manylinux_2_17) to manylinux_2_28 streamlink-appimage#3

The wheels which are missing could theoretically be built manually in separate repos here using GitHub CI, so the wheels could then be downloaded by the Windows builds and Linux AppImages from GitHub release assets instead of PyPI (where they are missing), but this requires maintenance of lots of build scripts for those third-party dependencies and their own dependencies. I absolutely don't want to spend any time on that, so this is not going to happen. I also don't want to have to deal with more dependency overrides in the build configs.

lxml 4.9.3 which was released in July still hasn't published py312 wheels for win32 and for i686 (on manylinux2014 aka. manylinux_2_17), and their most recent release from yesterday (4.9.4) has exactly the same issue. I had already pointed this out on their issue tracker in October when py312 was released, but this issue didn't get any attention by the project's developer until yesterday when I asked again while pointing out new issues. I didn't get a reply, but some of the pointed out issues like a PyPI deploy issue appear to be resolved now or are being worked on according to the project's commit log. Not sure though when all the missing wheels will be fully resolved by a new release.

As you can see, it's been almost three months now and the issue still remains.

Reasoning

So why keep 32-bit Windows builds and Linux AppImages, even if those dependency issues may get fixed in the future?

x86 is not relevant today anymore. The last CPUs of that kind were built in 2008/2009 while 32-bit processors were deprecated for a long time already at that time. Those specific CPUs were low-power Intel Atom N2xx/Z6xx mobile chips (Intel ARK / Wikipedia). I don't think keeping builds for x86 (win32/i686) makes sense, considering that the number of actual users with CPUs from dozens of generations ago is tiny.

Windows builds

I'm saying this because I'm pretty sure that most users on Windows who install the 32-bit builds simply don't care which one they choose, as it's compatible on x86_64 systems anyway, or they don't know what they're doing and just choose anything without reading. According to the Steam hardware survey, which I'm aware is not an accurate source (it's the best one available though since there's nothing official from MS - and Windows is primarily/exclusively a desktop OS, so Steam gaming hardware survey is kind of okay), there are basically no users of x86 Windows 10/11 (does MS even support this?), and the last remaining users of x86 are stuck on Windows 7, which is already dead for 9 years (or 4 years with extended security updates). I don't care about users running an x86 OS on their x86_64 CPUs.

We still provide Python 3.8 builds for users of Windows 7, because people complained when we bumped the installers to py39 a few years ago, but py38 will finally see its own EOL next year, and I will definitely pull the plug on these builds by then. So with the other market share stats in mind, this means that there will be no reason to keep 32-bit Streamlink builds for Windows. The streamlink/python-windows-embed and streamlink/FFmpeg-Builds repos then also won't have to build x86 release files anymore.

The chocolatey package already only provides the 64-bit installer. scoop and winget however support both architectures for some reason, but not the py38 builds.

AppImages

On Linux, the situation is a bit different. Compatibility isn't granted on x86_64 systems, which means you need to have 32-bit multiarch/compatibility packages of glibc, fuse and zlib installed on your system, which isn't the case for the vast majority of users who actually need the AppImages due to lack of available and updated Streamlink packages on their distro. It's far more likely that people who are actually using the i686 AppImages are running these on old and repurposed hardware because it's being run in a headless server configuration or what not. Maybe also on embedded devices or similar. Consuming modern streaming media surely isn't a pleasant experience on this old hardware, so I can't see these being used in a regular (desktop) use-case, except when using Streamlink for recording purposes only.

Lots of Linux distros also have already phased out i686 entirely, or are in the process of doing so. Distros like Debian which explicitly support outdated CPU architectures have up-to-date versions of Streamlink in their package repos, including its dependencies, so the AppImage is not needed. This renders the i686 AppImage even more irrelevant.

<edit>
Debian apparently will be dropping support for i386 in the near future, meaning it'll only be supported as multiarch on x86_64 host systems:

• https://lists.debian.org/debian-devel-announce/2023/12/msg00003.html
• https://www.theregister.com/2023/12/19/debian_to_drop_x86_32/

</edit>

Download stats

Here are the download stats from the last 20 releases summed up (when py311 was added, which was 5.1.2-2 from last December).

$ curl -sSL "https://api.github.com/repos/streamlink/windows-builds/releases" \
  | jq '.[0:20] | map(.assets[] | {key: .name, value: .download_count}) | from_entries' \
  > downloads-windows-builds.json
$ curl -sSL "https://api.github.com/repos/streamlink/streamlink-appimage/releases" \
  | jq '.[0:20] | map(.assets[] | {key: .name, value: .download_count}) | from_entries' \
  > downloads-appimage.json

$ for flavor in py38-x86 py38-x86_64 py311-x86 py311-x86_64; do \
    echo -n "$flavor: "
    jq -r "with_entries(select(.key | match(\"$flavor\\\\.\"))) | add" downloads-windows-builds.json
  done
py38-x86: 2427
py38-x86_64: 16650
py311-x86: 18896
py311-x86_64: 114415

$ for flavor in aarch64 i686 x86_64; do
    echo -n "$flavor: "
    jq -r "with_entries(select(.key | match(\"$flavor\\\\.\"))) | add" downloads-appimage.json
  done
aarch64: 750
i686: 258
x86_64: 4423

On Windows, 13.99% of all downloads are x86, while on Linux, it's 4.75%.

These 13.99% however don't mean much, because as said, it's compatible on x86_64. Running the i686 Linux AppImages on a x86_64 system won't work though unless the required 32-bit-libs are installed, so it's at least a bit more accurate. But then you also have to consider why people use the AppImages in the first place, so the result is still very much skewed.

Actual users / feedback

So who are the actual users here? Are there any?

I'd like to see some use-cases, so keeping the 32-bit builds can be justified.

Other upcoming changes

As mentioned, py38 will be dropped from the Windows builds, so Windows 7 and 8 won't be supported anymore.

The Linux AppImages also will be bumped next year in summer to manylinux_2_28 when support for manylinux2014/manylinux_2_17 runs out. This means that old distros won't be supported anymore and at least glibc 2.28 will be required (released in August 2018 - packaged by distros later).

[daspryJ]

I think I mistakenly downloaded & installed the 32-bit windows version a while back, trying to update my 64-bit version. Took me a while to realize, too. I'm dumb, but I might not be the only one who did that...

[bastimeyer]

Quick update...

$ curl -sSL https://pypi.org/pypi/lxml/4.9.4/json \
  | jq -r '.urls[] | select(.python_version == "cp312" or .python_version == "cp311") | .filename'
lxml-4.9.4-cp311-cp311-macosx_11_0_universal2.whl
lxml-4.9.4-cp311-cp311-manylinux_2_12_i686.manylinux2010_i686.manylinux_2_24_i686.whl
lxml-4.9.4-cp311-cp311-manylinux_2_17_aarch64.manylinux2014_aarch64.manylinux_2_24_aarch64.whl
lxml-4.9.4-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.manylinux_2_24_x86_64.whl
lxml-4.9.4-cp311-cp311-manylinux_2_28_aarch64.whl
lxml-4.9.4-cp311-cp311-manylinux_2_28_x86_64.whl
lxml-4.9.4-cp311-cp311-musllinux_1_1_aarch64.whl
lxml-4.9.4-cp311-cp311-musllinux_1_1_x86_64.whl
lxml-4.9.4-cp311-cp311-win32.whl
lxml-4.9.4-cp311-cp311-win_amd64.whl
lxml-4.9.4-cp312-cp312-macosx_11_0_universal2.whl
lxml-4.9.4-cp312-cp312-manylinux_2_28_aarch64.whl
lxml-4.9.4-cp312-cp312-manylinux_2_28_x86_64.whl
lxml-4.9.4-cp312-cp312-musllinux_1_1_aarch64.whl
lxml-4.9.4-cp312-cp312-musllinux_1_1_x86_64.whl
lxml-4.9.4-cp312-cp312-win32.whl
lxml-4.9.4-cp312-cp312-win_amd64.whl

The missing cp312 win32 wheels of lxml have been published now, so the Streamlink Windows builds could be updated from Python 3.11 to Python 3.12 now (other dependencies with Python C-extensions are already compatible). The decision now is keeping the x86 builds despite them being pretty much useless considering that Windows 10+ is already a requirement and no one is running these versions of Windows on x86, or remove them with the removal of the Python 3.8 builds (next year in October) which are required for the already long dead Windows 7 which might still have x86 users? Removing everything old in one go prior to the EOL of Python 3.8 could also be an option.

For the Linux AppImages, there's a dead end at Python 3.11, because lxml requires manylinux_2_28 for Python 3.12. This means that upgrading Streamlink's AppImages from Python 3.11 to Python 3.12 also means upgrading from manylinux2014 aka. manylinux_2_17 to manylinux_2_28. The manylinux_2_28 docker images which the AppImages are built off however are based on AlmaLinux 8 instead of CentOS 7, and there are no i686 builds available, which means the road definitely ends here. Considering that Debian is also already preparing the end of their support for i686 for their OS-images (not multilib of course), I don't feel bad making the choice of upgrading the AppImages to Python 3.12 and dropping i686. Streamlink can always be installed manually in a virtual environment on older Python versions.

[bastimeyer]

The Windows builds have been bumped from Python 3.11 to Python 3.12 now. The 3.12-based x86 builds will be kept until Python 3.8 got dropped, which will be in October. Should any issues come up prior to Python 3.8's EOL date, then those 3.8-based builds will be gone immediately.

The Linux AppImages can't be bumped right now, as explained. They will stay on 3.11 for now until the manylinux_2_28 upgrade has been completed, which is currently stuck due to an issue with the docker image's build config in regards to OpenSSL. Solving this may require a fork of the manylinux docker image build-repo, or a switch to python-build-standalone, which is a bit annoying. Then the i686 AppImages will be dropped.

[WolfganP]

I'm using the 64b builds on windows since long ago, in fact, the existence of 32bit builds just made me download them a couple of times due to not paying attention to the filenames... so I contributed to the 32b stats by mistake :)

Same on a traveling laptop, updating via the 64b appimage builds every time I begin the trip.

[bastimeyer]

The Linux AppImages can't be bumped right now

lxml has published new 5.0.1 and 5.1.0 releases, with an updated wheel build config where manylinux2014/manylinux_2_17 is supported by their cp312 wheels on all CPU architectures. Since this resolves all dependency issues, the Python version in the AppImages can be bumped from 3.11 to 3.12. I've already built and checked the AppImages and they were working fine. I'll update the build config later...

manylinux2014 will however still be dropped once its support ends in a few months, which will mean the end of i686.