Don't preinstall setuptools and wheel, remove from constraints #1725
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Reasons to do this: - setuptools is no longer the only game in town. When cibuildwheel was created, setuptools was the only way to make wheels. these days, there are many build backends so special casing setuptools doesn't make so much sense - we don't need to preinstall `wheel` any more, setuptools will do that itself when it needs it. - projects with pyproject.toml (i.e. the vast majority of projects going forward) don't benefit from the pin anyway, because both `pip` and `build` create an isolated environment to install `build-system.requires` into. - this makes it easier for end users (such as @webknjaz) to control build-system versions using `PIP_CONSTRAINT`, because there's less potential for a user-specified version to conflict with one of our pins. - (long-term, I'd love `build` to [support this directly](pypa/build#292), and then we could have a proper way to keep pyproject.toml dependencies loose and forward-compatible while retaining build determinism. But PIP_CONSTRAINT is the best we have for now. PIP_CONSTRAINT isn't ideal because it affects other things, like the test virtualenv). This PR also adds a pin for pypa/build. It appears that was missing before, but we should pin it.
webknjaz
reviewed
Jan 21, 2024
|
Would it make sense to get a release out before this? PyPy had a bug that broke NumPy's CI, and they had to pin on an older version, and we updated PyPy weeks ago, but haven't released yet. This seems like a bigger change that should sit in main a bit, but we are well past due on a a release with the latest PyPy. |
webknjaz
approved these changes
Jan 22, 2024
Apologies, I missed the PyPy stuff over the holidays. I'll get a release out today/tomorrow. |
|
@joerick since that release is out, should this be merged now? |
henryiii
approved these changes
Feb 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reasons to do this:
wheelany more, setuptools will do that itself when it needs it.pipandbuildcreate an isolated environment to installbuild-system.requiresinto.PIP_CONSTRAINT, because there's less potential for a user-specified version to conflict with one of our pins.buildto support this directly, and then we could have a proper way to keep pyproject.toml dependencies loose and forward-compatible while retaining build determinism. But PIP_CONSTRAINT is the best we have for now. PIP_CONSTRAINT isn't ideal because it affects other things, like the test virtualenv).This PR also adds a pin for pypa/build. It appears that was missing before, but we should pin it.