Add py3-none-any wheel to distribution artefacts
envgap__coveragepy__coveragepy-1912
01 / FAILURE SIGNATURE
As reported upstream
No identifying execution failure has been captured.
Not a benchmark task.
- The project already builds and runs before the fix, so there is nothing to repair.
02 / ENVIRONMENT RECIPE
- Base commit
4fa393a3453642754f79d084edabb9718d8483cf- Manifest
setup.py- Reproduce
Awaiting issue-specific recipe- Run under trace
Awaiting a meaningful runtime command
03 / ORIGINAL ISSUE TEXT
coveragepy/coveragepy #1912 · read the original issue
**Is your feature request related to a problem? Please describe.** Coverage contains a binary module to provide an optimised path for gathering coverage data. As a result, Coverage is published used platform-specific binary wheels. If you're in an environment that *doesn't* have an officially published wheel, you need to install from source. However, cross-platform builds (such as mobile platforms like iOS and Android) can *require* the use of `--use-binary=:all:` when installing. These platforms need to use `--platform` to force the installation of wheels on a platform other than the one they're currently on; using `--platform` also requires the use of `--use-binary=:all:`, as pip can't guarantee it will be able to run the build entry point for a source distribution. **Describe the solution you'd like** Coverage should publish a py3-none-any wheel as part of standard release artefacts. This would allow a wheel-based install of a non-optimized version of coverage on platforms that don't have an official wheel. pip will preferentially install platform-specific wheels over py3-none-any wheels, so the optimised binary wheel should take precedence over the non-optimized wheel wherever possible. **Describe alternatives you've considered** Publish optimised binary wheels for platforms affected by this problem. This is likely a better long-term solution; however, at present, cibuildwheel can't produce iOS wheels. We (BeeWare) are currently working on this, but there won't be a fix in place for (at best) a couple of months. **Additional context** This problem emerged recently as a result of a change in pip 24.3, which adds iOS support. Historically, the process for installing wheels on iOS has involved using a site-packages hack to fake an iOS environment inside a macOS virtual environment, tricking pip into installing iOS wheels with the `--prefer-binary` option. `--prefer-binary` will fall back to a source distributions if no binary can be found, and with the right hacks in `site-packages`, it's possible to force this environment to produce a non-optimized coverage wheel for iOS installation. As an immediate workaround, BeeWare is currently publishing iOS binary wheels in its [independent iOS wheel repo](https://anaconda.org/beeware/coverage). However, we'd rather not be an official distributor of coverage in the long term. The one downside of publishing a py3-none-any wheel is that platforms that *don't* require the use of `--use-binary=:all:`, and don't have an official binary in PyPI, will no longer get a "compiled at time of installation" binary optimised install. However, those users would be able to compile and install their own binary wheels. This would only affect users on niche platforms (old Linuxes not covered by a published manylinux platform, other Unixes, etc).
04 / LABELS
Labels from the report text only; not yet run
No supported category has been assigned.
Label rules and the text that matched
[]