Skip to content

chore: wheel is not required for setuptools#289

Open
henryiii wants to merge 1 commit intopython-lz4:masterfrom
henryiii:patch-2
Open

chore: wheel is not required for setuptools#289
henryiii wants to merge 1 commit intopython-lz4:masterfrom
henryiii:patch-2

Conversation

@henryiii
Copy link
Copy Markdown

Wheel has never been required in build-system.requires unless you used import wheel in setup.py (which you should not, wheel doesn't have a public API) - it's requested by setuptools via a hook. And modern setuptools doesn't even use wheel anymore.

@jonathanunderwood
Copy link
Copy Markdown
Member

Builds failing.

@henryiii
Copy link
Copy Markdown
Author

Same thing on master, too, from what I can tell.

@henryiii
Copy link
Copy Markdown
Author

henryiii commented Oct 16, 2024

This request has been automatically failed because it uses a deprecated version of actions/upload-artifact: v2. Learn more: https://github.blog/changelog/2024-02-13-deprecation-notice-v1-and-v2-of-the-artifact-actions/

You have to keep actions up to date. Old actions stop working. Dependabot can do this, but you need to tell it to group actions, so that upload/download stay in sync.

@cclauss
Copy link
Copy Markdown
Contributor

cclauss commented Oct 23, 2025

Please rebase.

@henryiii
Copy link
Copy Markdown
Author

Done

@cclauss
Copy link
Copy Markdown
Contributor

cclauss commented Apr 15, 2026

@henryiii Would you be willing to help determine why

@henryiii
Copy link
Copy Markdown
Author

Sure, I believe it's because you have the (default) pining active. Our docs aren't actually correct here, but that does actually affect linux too when installing the testing environment. We pin a core set of dependencies, which is virtualenv and its dependencies, which pins python-discovery, and that causes tox to break, since it needs a really new python-discovery. (BTW, @gaborbernat, tight lower bounds + fast releases is hard to manage!)

For your package, I'd recommend just setting dependency-versions = "latest". There's really very little benefit to pinning these days; it used to be we could pin the build backend (because there was only one, setuptools), which might have improved reproducibility, but now it's pretty much just virtualenv, pip, and build.

This (combined with my kimi-K2.5 analysis of the situation) exposes an issue in cibuildwheel: I know the docs say this doesn't affect linux, the llm noticed we don't even allow linux.depedency-versions to be set (overrides still work, though), but we do take it into account when installing the testing phase (which you saw). We removed this affecting the build in v3.3.0 (also noted by the analysis), but it's still present in the test step for linux.

I'll open an issue in cibuildwheel to see if we can iron this out. At the least, hopefully we can update our pins, but I don't want build 1.4.3 to get pinned (1.4.4 should be out soon), so it will be a few days (has to trickle down to manylinux too).

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.

3 participants