mu-editor
Download only wheels?
Prior to the venv creation, we attempt to download wheels. If we can't, this can sometimes cause -- eg in the case of pygame -- an attempt to build some complex packages.
Is it worth specifying --only-binary when we pip download? If so, maybe only for certain packages as, eg, nudatus is source only but is pure Python so there's no problem if a wheel isn't available
This only affects development environments and packaging? I like the idea, but might have to try it out to understand possible failure modes.
FWIW, by using --only-binary, relaxing versions and using a single gohlke wheel (pygame 1.9.6), Mu is running and passing all tests on Python 3.9 (64-bits, Windows). No device to test interaction and didn't try packaging.
Thanks for giving this a go @devdanzin. By and large the problem isn't Windows (where binary builds are quite common, including the hard-working Gohlke set) but the other platforms where they're less common, relying perhaps on distro-built pygame installs etc.
It does affect only dev environments (including those who care to run live via a venv) and packaging. But those are two different needs: a developer can do whatever they wish to get a working runtime venv, including using 3rd-party wheels. But the packaging needs wheel files to be available in the mu\wheels directory.
If nudatus was the only package without wheels (I doubt it), then we could just ask @ZanderBrown to update it. However, it would probably be quite hard for that to always be the case as third party dependencies can be unpinned.
I think at the very least we can use the "prefer binary" option, which I think tries to find a compatible version with wheels before getting the source. Taking in consideration how often we get issues with a Mu pip installation trying to build pygame or other dependencies from source (now less common, but numpty and matplotlib were also common failures at some point), then I think it would be good to ensure that at least the "risky" packages are only fetched as wheels.
Ah; I didn't know about the --prefer-binary switch. That seems to me like a useful compromise here. I'll put a quick change through later
If the only or prefer binary options have not been added yet it could be the cause of issues like thiese:
- https://github.com/mu-editor/crash-reports/issues/84
- https://github.com/mu-editor/mu/issues/1391#issuecomment-950358836
Probably pip could have found an older version of cffi with a valid wheel for that platform instead of trying to build it from source.