search

pybind / cmake_example

Example pybind11 module built with a CMake-based build system
Other
616 stars 218 forks source link

chore(deps): bump pypa/cibuildwheel from 2.2.0 to 2.3.0 #66

Closed dependabot[bot] closed 2 years ago

dependabot[bot] commented 2 years ago

Bumps pypa/cibuildwheel from 2.2.0 to 2.3.0.

Release notes

Sourced from pypa/cibuildwheel's releases.

v2.3.0

  • 📈 cibuildwheel now defaults to manylinux2014 image for linux builds, rather than manylinux2010. If you want to stick with manylinux2010, it's simple to set this using the image options. (#926)
  • ✨ You can now pass environment variables from the host machine into the Docker container during a Linux build. Check out the docs for CIBW_ENVIRONMENT_PASS_LINUX for the details. (#914)
  • ✨ Added support for building PyPy 3.8 wheels. (#881)
  • ✨ Added support for building Windows arm64 CPython wheels on a Windows arm64 runner. We can't test this in CI yet, so for now, this is experimental. (#920)
  • 📚 Improved the deployment documentation (#911)
  • 🛠 Changed the escaping behaviour inside cibuildwheel's option placeholders e.g. {project} in before_build or {dest_dir} in repair_wheel_command. This allows bash syntax like ${SOME_VAR} to passthrough without being interpreted as a placeholder by cibuildwheel. See this section in the docs for more info. (#889)
  • 🛠 Pip updated to 21.3, meaning it now defaults to in-tree builds again. If this causes an issue with your project, setting environment variable PIP_USE_DEPRECATED=out-of-tree-build is available as a temporary flag to restore the old behaviour. However, be aware that this flag will probably be removed soon. (#881)
  • 🐛 You can now access the current Python interpreter using python3 within a build on Windows (#917)

v2.2.2

  • 🐛 Fix bug in the GitHub Action step causing a syntax error (#895)

v2.2.1

  • 🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)
  • 🐛 Fix missing resources in sdist and released wheel on PyPI. We've also made some internal changes to our release processes to make them more reliable. (#893, #894)

v2.2.1b1

  • 🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)
  • 🐛 Fix missing resources in sdist and released wheel on PyPI. We've made some internal change to our release processes to make them more reliable. (#893, #894)
Changelog

Sourced from pypa/cibuildwheel's changelog.

v2.3.0

26 November 2021

  • 📈 cibuildwheel now defaults to manylinux2014 image for linux builds, rather than manylinux2010. If you want to stick with manylinux2010, it's simple to set this using the image options. (#926)
  • ✨ You can now pass environment variables from the host machine into the Docker container during a Linux build. Check out the docs for CIBW_ENVIRONMENT_PASS_LINUX for the details. (#914)
  • ✨ Added support for building PyPy 3.8 wheels. (#881)
  • ✨ Added support for building Windows arm64 CPython wheels on a Windows arm64 runner. We can't test this in CI yet, so for now, this is experimental. (#920)
  • 📚 Improved the deployment documentation (#911)
  • 🛠 Changed the escaping behaviour inside cibuildwheel's option placeholders e.g. {project} in before_build or {dest_dir} in repair_wheel_command. This allows bash syntax like ${SOME_VAR} to passthrough without being interpreted as a placeholder by cibuildwheel. See this section in the docs for more info. (#889)
  • 🛠 Pip updated to 21.3, meaning it now defaults to in-tree builds again. If this causes an issue with your project, setting environment variable PIP_USE_DEPRECATED=out-of-tree-build is available as a temporary flag to restore the old behaviour. However, be aware that this flag will probably be removed soon. (#881)
  • 🐛 You can now access the current Python interpreter using python3 within a build on Windows (#917)

v2.2.2

26 October 2021

  • 🐛 Fix bug in the GitHub Action step causing a syntax error (#895)

v2.2.1

26 October 2021

  • 🛠 Added a config-file option on the GitHub Action to specify something other than pyproject.toml in your GitHub Workflow file. (#883)
  • 🐛 Fix missing resources in sdist and released wheel on PyPI. We've also made some internal changes to our release processes to make them more reliable. (#893, #894)
Commits


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
henryiii commented 2 years ago

@mattip, @joerick, @mayeut - this is weird. Will look into it later (traveling), but cibuildwheel 2.3 breaks PyPy on macOS (3.8 only) (still 10.15) and Linux (3.7) but not being able to get the ninja binary from the PEP 518 requirement. It seems to not be able to handle PEP 517 isolation correctly? No idea if it’s PyPy or Pip or something else.

mattip commented 2 years ago

This succeeds for me

$ git clone https://github.com/pybind/cmake_example
$ cd cmake_example
$ export CIBW_BUILD=pp37-manylinux_x86_64
$ python -c "import cibuildwheel as ci; print(ci.__version__)"
2.3.0
cibuildwheel --platform=linux

Although for some reason the wheel is not copied back to the host.

Maybe increase verbosity so we get a log of what is going on?

mayeut commented 2 years ago

CIBW_BUILD=pp37-manylinux_x86_64 cibuildwheel --platform=linux succeeds (the wheel is copied back in my case). CIBW_BUILD=*37-manylinux_x86_64 cibuildwheel --platform=linux fails. This is true for both pip & build frontends.

The issue comes down to a lack of isolation between builds. Adding before-build = "rm -rf {project}/build" solves the issue. If using the pip frontend, before-build = "python -m pip install -U pip==21.2.4" also does the trick. My best guess is that due to caching, cmake is trying to use the ninja it found during the cp37 build while building for pp37. That ninja is not present anymore after a the cp37 build ends.

We might want to report this to setuptools, it's probably not a good idea to cache builds for different interpreters (they already have python version segregation - 3.7, 3.8, ...-, it should probably go further than that).

I have not yet investigated the macOS failure but I can hazard that something similar is happening.

henryiii commented 2 years ago

I expect that setting the old copy behavior would then also fix it (PIP_USE_DEPRECATED=out-of-tree-build). I can try that to see if that's the problem.

mayeut commented 2 years ago

Build is OK for linux but this raises another issue for cibuildwheel to solve (maybe ignore PIP_* environment variables when setting up the build environment) ?

henryiii commented 2 years ago

Those could be very important in the build environment, though. For example, if a package depends on setuptools in pyproject.toml, setting the constraints via pip variables is the only way to limit setuptools if something breaks (like the removal of the 2to3 support).

The main problem here is pip 21.1 is being used on Windows when I thought it was supposed to be locked to 21.3 on all platforms? Ahh, I see what you mean. We should ignore PIP_ variables during the setting up of our cibuildwheel constraints. Shouldn't we ignore all environment variables there, perhaps? Given that's really just our setup process.

henryiii commented 2 years ago

Unrelated PS: @mayeut I sent you a message on discord a while back.

henryiii commented 2 years ago

FWIW, build backend has the same issue (since it't a setuptools issue, not surprising, but still noting it)