Skip to content

Don't preinstall setuptools and wheel, remove from constraints - #1725

Merged
joerick merged 6 commits into
mainfrom
constraints-cleanup
Feb 28, 2024
Merged

joerick merged 6 commits into
mainfrom
constraints-cleanup

Conversation

@joerick

@joerick joerick commented Jan 20, 2024

Copy link
Copy Markdown
Contributor

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, 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.

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.
Comment thread test/test_dependency_versions.py Outdated
Comment thread test/test_dependency_versions.py Outdated
@henryiii

Copy link
Copy Markdown
Contributor

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.

@joerick

joerick commented Jan 26, 2024

Copy link
Copy Markdown
Contributor Author

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

Apologies, I missed the PyPy stuff over the holidays. I'll get a release out today/tomorrow.

@webknjaz

Copy link
Copy Markdown
Member

@joerick since that release is out, should this be merged now?

@joerick
joerick requested review from henryiii and mayeut February 27, 2024 21:46
@joerick
joerick merged commit 8742ff2 into main Feb 28, 2024
@joerick
joerick deleted the constraints-cleanup branch February 28, 2024 09:16
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