Fix for #1803, where the method used for merging the config-settings option - string concatenation - was of little use.
I broke out the TableFmt object into a protocol-like object called OptionFormat, where the formatting and merge rules can be customised more deeply. This is more explicit, and lets us be a bit more precise with how TOML object get converted into the options.
I intend to use the flexibility of the OptionsFormat structure to tackle the remaining abiguity around environment variable quoting, as seen in the xfails in the options_test.py unit test and discussed in #1271.
Co-authored-by: Matthieu Darbois <mayeut@users.noreply.github.com>
* 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>
* Fix executable name, that doesn't always exist on windows
* Use the `python3` executable on macOS Cirrus
* Homebrew changed where it puts the python binaries
* Update examples to match new config
Fix#1612
The hassle of updating these pins (both for us and our users, most copy our documentation) seems to outweigh the benefit of the pin. The truth is that they're not really pins anyway, Github update them all the time, and they don't work for historical repeatability because old images are retired all the time.
Historically, we required `--platform` when running cibuildwheel outside of CI, because cibuildwheel would attempt to globally install Python interpreters and some packages.
That was fixed in https://github.com/pypa/cibuildwheel/pull/974 a couple of years ago. As a result, there's no reason to require --platform these days, the `auto` behaviour is perfectly fine for dev machines.
It also makes running tests locally simpler, one can just do `pytest test/test_0_basic.py` (or `nox -s tests -- test/test_0_basic.py`) and not have to worry about setting CIBW_PLATFORM most of the time.
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.
Joe Rickerby