Missing FAQs

[bennuttall]

Got a question about piwheels? Ask it here and we'll consider adding it (and the answer) to the FAQs.

[bennuttall]

• How to download wheels for offline installation: Missing package: p4p packages#117 (comment)
• How can I force installation of Armv6 wheels?
• Hash mismatch
• Requires-Python
• Deleted
• Yanked
• sudo/pip3?
• manylinux2014

[amundgr]

I have tried to look for an answer to this online, but I can't seem to find it so here I go:

Why are there no python 3.6 wheels for numpy, python-opencv, matplotlib, etc.? I feel like I am missing something obvious, but I just can't seem to find the answer anywhere. Sorry if this is the wrong place to ask.

[bennuttall]

It's mentioned on the homepage that we provide wheels for Jessie/Stretch/Buster and this is covered in the FAQs but I could add more detail about versions we don't build for. Here's what it says:

We build for the ABI of the Python 3 version distributed with Debian releases:

Jessie - Python 3.4
Stretch - Python 3.5
Buster - Python 3.7

Each Debian release comes with a specific Python version, shown above. We build wheels using the system Python in each of these Debian versions. There is no Debian release with Python 3.6, so we don't build 3.6 wheels. Buster is the latest stable Debian release, and it comes with Python 3.7. We won't build for any further Python versions until the next stable Debian release is available.

It's possible to build other Python versions from source, so why don't we do this and build wheels for every Python version? Two reasons:

• Since users could build any minor version at any release stage, there's no guarantee wheels we built with a specific Python version would be compatible with the one a user is using. Plus, If we built with 3.9 beta, we'd probably have to rebuild once it was released. If we built with e.g. 3.9.1, then 3.9.2 comes out, should we move to that? Or rebuild existing wheels?

• Python packages often depend on shared libraries provided by apt packages. The python3- packages are build against the system Python, so there's no guarantee wheels we build would be compatible.

Hope that helps. Will aim to write a concise version of this up for the FAQs.

[wolet-ft]

Are there plans to move to Python 3.8 or even 3.9 for Buster? There is currently a problem with asyncio (CookieError) for Python versions < 3.8 (see: freqtrade/freqtrade#4356, or https://github.com/encode/starlette/blob/99b37781eb88cfc2f7064724975ac5d93d623ea7/starlette/responses.py#L17-L18)

[bennuttall]

No - we only build for system Python versions - but Bullseye comes out this summer with 3.9. See my previous comment as to why.

[wolet-ft]

Cool!

[jedie]

Oh, i found this issue entry now, after creating Include piwheels into lock file #260 ... Don't know it it's a entry for FAQ?!?

[gpongelli]

Similar question from previous comment, but two year later: are there plan to support bookworm (or, more generally, any testing) release?
What about python 3.10 and 3.11 support?

[bennuttall]

We'll start building for 3.11 on Bookworm as it gets close to release.

[gpongelli]

We'll start building for 3.11 on Bookworm as it gets close to release.

Isn’t it already released?
I see official images are already bookworm based.

[bennuttall]

No, they're Bullseye.

https://www.debian.org/releases/bookworm/

[gpongelli]

Sorry, I often confuse them.

So, generally speaking, Debian testing branch is not planned to be supported (even if it can be installed in rpi), right?

[bennuttall]

No, it wouldn't be useful as the dependencies packages are build against would change over time.