* Refactor error handling to use exceptions
cibuildwheel has up until now handled most errors by printing an error message to sys.stderr and calling sys.exit. Others were handled using Logger.error, depending on the context. We also had return codes, but these weren't explicitly defined anywhere.
This makes that convention more explicit and codified. Now to halt the program, the correct thing to do is to throw a cibuildwheel.errors.FatalError exception - that is caught in main() and printed before exiting. The existing behaviour was kept - if an error occurs within a build step (probably something to do with the build itself), the Logger.error() method is used. Outside of a build step (e.g. a misconfiguration), the behaviour is still to print 'cibuildwheel: <message>'
I also took the opportunity to add a debugging option `--debug-traceback` (and `CIBW_DEBUG_TRACEBACK`), which you can enable to see a full traceback on errors.
(I've deactivated the flake8-errmsg lint rule, as it was throwing loads of errors and these error messages aren't generally seen in a traceback context)
* add noqa rule
* Apply suggestions from code review
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Return to flake8-errmsg conformance
* Code review suggestions
* Subclass Exception rather than SystemExit
* apply error handling to new code and fix merge issues
* Apply review suggestion
* fix: merge issue
* Update cibuildwheel/errors.py
---------
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Co-authored-by: mayeut <mayeut@users.noreply.github.com>
* replace `with suppress(FileNotFoundError)` by `.unlink(missing_ok=True)` for macos
* also use `.unlink(missing_ok=True)` in pyodide and windows for consistency
* remove contextlib imports which are no longer required
* Apply suggestions from code review
* explicity resolve and create output location
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* use explicit str for move
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* update comments based on review feedback
* Apply suggestions from code review
* Break out functionality to move files to util.py
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* raise instance of IsADirectoryError with meaningful message
* Don't need a comment and a exception message
---------
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
When building a project that has a `pyproject.toml`, constraints
are not respected when building with the `pip` frontend.
This commit fixes this by using the same tricks as for the `build` frontend.
* Set SYSTEM_VERSION_COMPAT=0 during pip install on macos (#1767)
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Only set SYSTEM_VERSION_COMPAT=0 for CPython 3.8
* Set SYSTEM_VERSION_COMPAT=0 for CPython <= 3.8
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update cibuildwheel/macos.py
Co-authored-by: Joe Rickerby <joerick@mac.com>
* Update cibuildwheel/macos.py
Co-authored-by: Joe Rickerby <joerick@mac.com>
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Joe Rickerby <joerick@mac.com>
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](https://github.com/pypa/build/issues/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.
This was incorrectly adding an empty config setting, and it was not correct if included for build - it's a pip wheel only setting. Reported in #1471.
Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
Instead of using pip as the default, set it to default. This way
each platform can choose independently what to do as the default
behavior.
This is intended as part of adding Pyodide support. Pyodide cannot
use pip as the build frontend. It always uses a modified pypa/build.
So if the build_frontend is explicitly set to pip we want to raise
an error. But if it's unset, then we should be able to tell and just
do what we want.
* Add structually typed GenericPythonConfiguration
Use structural typing for the return value of get_python_configurations
so that we don't have to specify a union of all possible PythonConfiguration
types
* address henryiii's comments
* Use Set in more places
When `MACOSX_DEPLOYMENT_TARGET` is not set by the user, cibuildwheel always defaults to `10.9`.
This leads to warning when building arm64 wheels.
This commit removes the warning by setting the default to `11.0` for arm64 builds.
Per discussion in https://github.com/pypa/cibuildwheel/pull/1169, the default installer used for cp38 is an Intel installer.
It makes sense to skip testing arm64 wheels in this case.
However, if the user choose to manually install the universal2 CPython version, then, tests shall be run on arm64.
This allows users that either target 11.0+ on intel, universal2 or only build for arm64 to get the arm64 wheel tested on AppleSilicon.
* feature: add support for `py3-none-{platform}` wheels
This extends the mechanism introduced in #1091 for `abi3` wheels.
Most of the mentions to `abi3` have been removed and replaced by a more generic `compatible_wheel`.
This allows to build a wheel `foo-0.1-py3-none-win_amd64.whl` only once and still test with every configured python.
* Add integration test for py3-none abi wheels
* Fix expected_wheels for py3-none abi
* Limit test to three pythons and check for certain log messages
* chore: add some comments to explain filter process
Co-authored-by: Joe Rickerby <joerick@mac.com>
Co-authored-by: Henry Schreiner <henryschreineriii@gmail.com>
Matthieu Darbois