* Write docs for inline dependency-versions
* Change the `inline` keyword to `packages` for better readability
* Implement inline package constraints
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Add schema for TOML properties
* Change the parsing of the option to parse filenames as-is
* Add a unit test for table-parsing of the option
* Remove unneeded shlex.quote on the dependency-version test
* Tidy-ups, comments, docs fixes
* Add test for empty packages option value
* Fix empty packages scenario
And, remove some optionals to reduce the problem space
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* optimise unit tests - Cache loading the config TOML
Unit test time: 13.1s -> 10.5s
* optimise unit tests - use the same pyproject validator across the tests
Unit test time: 10.5s -> 5.7s
* optimise unit tests - selector optimisation
Unit test time: 5.7s -> 5.1s
* optimise unit tests - build options computation cache
Unit test time: 5.1s -> 3.2s
* Use functools.cache rather than functools.lru_cache
* Don't overwrite build_options when applying functools.cache
* feat: Print FatalError messages using Logger
This makes them appear GHA annotations in CI logs, which makes them easier to spot. I've also added the "cibuildwheel: " prefix to those errors, I think it helps when viewing a log to know which tool is talking to you - it can be difficult to understand with build tools.
* Nicer error message on invalid architecture
* Fix some message formatting and test expectations
The requirements pinning is done by uv now, so we don't need to
run the versions of Python to do the pinning anymore.
Cherry-picked from 37f7f611b208f48d4bb80a35eb31e39e47102930
* Add note about the planned change of the manylinux default
* Update docs/options.md
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Change date to 6th May
Co-authored-by: Matthieu Darbois <mayeut@users.noreply.github.com>
* no manylinux_2_28 pypy_i686 image
* no manylinux_2_28 i686 image
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
Co-authored-by: Matthieu Darbois <mayeut@users.noreply.github.com>
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
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