Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add py3-none-any wheels to the distribution artefacts #1914

Merged
merged 3 commits into from
Jan 10, 2025

Conversation

freakboy3742
Copy link
Contributor

Fixes #1912.

  • Adds support for generating py3-none-any wheels. If the user has COVERAGE_DISABLE_EXTENSION defined in their environment, no attempt will be made to compile a binary wheel, even if the platform would otherwise support building the binary extension
  • Adds a py3-none-any artefact to the build products of a normal build. A wheel was already being compiled as part of the sdist step; this ensures that (a) the wheel is a py3-none-any wheel, and (b) it's included in the release artefacts.

@freakboy3742
Copy link
Contributor Author

The kit action was triggered in my own repo (where it was a push trigger, rather than a pull_request); This is the run producing a py3-none-any wheel.

@nedbat
Copy link
Owner

nedbat commented Jan 10, 2025

Thanks!

But in your action I see:

> List non-binary artifacts
-rw-r--r--  1 runner docker 200525 Jan 10 01:49 coverage-7.6.11a0.dev1-py3-none-any.whl
-rw-r--r--  1 runner docker 804612 Jan 10 01:49 coverage-7.6.11a0.dev1.tar.gz

and in my last run of the action I see:

> List sdist
-rw-r--r--  1 runner docker 235413 Dec 26 16:45 coverage-7.6.10-cp39-cp39-linux_x86_64.whl
-rw-r--r--  1 runner docker 803868 Dec 26 16:45 coverage-7.6.10.tar.gz

Was my .whl there useless? Is it ok that it has a different name?

@freakboy3742
Copy link
Contributor Author

freakboy3742 commented Jan 10, 2025

The old sdist build rule ran python -m build, which will produce both a wheel (native to the local platform) and an sdist by default - that's what produced the cp39-cp39-linux_x86_64 wheel. However, the action then excluded all but the .tar.gz file from the uploaded artefacts.

This new config forces the "native" wheel to be py3-none-any, and includes it in the uploaded artefacts.

The old configuration could have been optimised slightly by invoking python -m build -s - that would have only produced the sdist. However, it's a moot point now, as we want the wheel as well.

@nedbat
Copy link
Owner

nedbat commented Jan 10, 2025

Sorry for all the questions. You say "The old sdist build rule ran python -m build", but that is still the command being run. The new config seems to be the environment variable disabling the compilation of the extension. That's enough to change the name of the result?

@freakboy3742
Copy link
Contributor Author

Invoking python -m build produces a wheel and an sdist. The command is running on Linux; so in the old configuration, a binary wheel is produced, because the extension module can be compiled.

In the new configuration, the compilation of the binary extension is disabled with the environment variable, but a wheel is still being produced; so the wheel identifies as py3-none-any.

@nedbat nedbat merged commit 40c40b6 into nedbat:master Jan 10, 2025
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add py3-none-any wheel to distribution artefacts
2 participants