* Revert to running tests from from a temp dir when test-sources is unset
* Fix placeholders error message, add test for it
* Add back {project} placeholders to CIBW_TEST_COMMAND in tests & docs
* Update test/test_before_test.py
---------
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* [travis-ci] debugging ci failures on travis
* [travis-ci] Use JSON to encode env vars
* [travis-ci] Use a more broadly compatible before_all command
* Drop CIBW_ENABLE=all on Travis windows
It doesn't fit into the time limit
* [travis-ci] try upgrading certifi to get around SSL errors
* Revert "[travis-ci] try upgrading certifi to get around SSL errors"
This reverts commit 02eee0e1946d2116d1ce23ccd86945ad33d1ae24.
* [travis-ci] upgrade windows certificates
* [travis-ci] re-enable linux builds
* Drop CIBW_ENABLE=all on Travis Linux
It doesn't fit into the time limit
---------
Co-authored-by: mayeut <mayeut@users.noreply.github.com>
* Add TEST_ENVIRONMENT option and set PYTHONSAFEPATH=1 in the test env
Closes https://github.com/pypa/cibuildwheel/issues/2358
* Add toml docs examples
* Add TOML examples
* Use double-quotes for windows
* Change to the iOS testing option semantics
Don't assume the presence of `python -m` in the test command. Less magic
and allows more option reuse between platforms.
* Update schema
* Add a test for this warning
* Don't try to execute a test-command when it doesn't look like a module
* Update docs/options.md
Co-authored-by: Malcolm Smith <smith@chaquo.com>
* Only allow invalid test command if the first part is 'pytest'
* Responses to code review from @freakboy3742
* Fixes post-merge
---------
Co-authored-by: Malcolm Smith <smith@chaquo.com>
* Improve integration test options
- Keep the platform and enable options in os.environ, don't duplicate state in utils
- Provide more user-friendly options for setting enable and platform in integration tests
* Ensure that CIBW_ENABLE is set in the test process
* Use get_enable_groups() where necessary
* Allow CIBW_ENABLE to control the wheels built in testing
* Set CIBW_ENABLE using PR labels
* Add docs
* Build everything on the main branch
* Add CIBW_ENABLE=all option
This was mostly for use in the `main` building case, because otherwise it's maybe a bit too easy to forget to update this file when adding an enable group
* Remove dead code
* Make unit tests robust to the value of CIBW_ENABLE
* Fix tests that explicitly choose pypy
* Fix test expectation
* Don't expect impossible wheels in expected_wheels
* Simplify logic in expected_wheels
* CircleCI- run with CIBW_ENABLE=all only on the main branch
* Azure pipelines - run with CIBW_ENABLE=all on main branch
* Update gitlab to run CIBW_ENABLE=all on main
* Set CIBW_ENABLE=all on travis - it only runs on main anyway
* Fix job name error on CircleCI
* Fix tests for graalpy
* Update the test configuration to use the label
* Remove duplication of default value. Make it affect sample build too
* Move the action to after deps are installed
* GraalPy workaround for this assumption
* Make unit test resilient to changing CIBW_ENABLE
* Split the docs into sections
* Split the options page into two pages - so the reference is more clean
* Reorder/Tidy up this 'deliver' page to make auto-deploy more obvious
* Fix up some links
* Merge the platform docs into a single page to clean up the navbar.
* Split the setup page to make a page dedicated to CI setup
* Move general platform-specific information into the platforms page
* Tidy up the platforms page
* Remove some redundancy in the cpp/platforms docs
* Clarify this section
* Move another FAQ entry to the platforms page
* Remove some out-of-date entries from the FAQ
* A few corrections to the options page
* Fix some broken links
* Improve the Docker references
* Update bump version filename
* Improve options TOC information density
* whitespace
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* Convert the normal test invocation to `pytest ./tests`, not placeholder
---------
Co-authored-by: Henry Schreiner <HenrySchreinerIII@gmail.com>
* feat: stricter selector parsing, refactor to `platforms` module
- Use a different method to build nothing
- Make the check aware of enable groups
* optimise unit tests - a specific platform module API for all configs
Unit test time: 26.2s -> 13.1s
* Remove unnecessary get_platform_module function
* 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