* xtask: move coverage implementation to nox
* move pytests from xtask to nox in ci
* use --package instead of --manifest-path for tests
* write github actions groups to sys.stderr
* ci: test on emscripten target
This adds CI to build libpython3.11 for wasm32-emscripten and
running tests against it. We need to patch instant to work
around the emscripten_get_now:
https://github.com/sebcrozet/instant/pull/47
We also have to patch emscripten to work aroung the "undefined
symbol gxx_personality_v0" error:
https://github.com/emscripten-core/emscripten/issues/17128
I set up a nox file to download and install emscripten,
download and build cpython, set appropriate environment variables
then run cargo test. The workflow just installs python, rust,
node, and nox and runs the nox session.
I xfailed all the test failures. There are problems with datetime.
iter_dict_nosegv and test_filenotfounderror should probably be
fixable. The tests that involve threads or asyncio probably can't
be fixed.
* Some cleanup
* Remove instant patch
* Add explanations for xfails
* Fix Windows OSError
* Ignore .pyd files
* Put things in modules
* Rename functions to `run`
* Expand on cargo xtask
* Try to work around missing installs
* Run all things by default, but not llvm-cov
* Test msrv
* Fix more OSErrors
* Various refinements and docs
* Various refinements
* Various refinements
* Add decorator example crate and split off chapter
* Move not-examples to their own folder
* Add some readme's
* Make black happy
* Make clippy happy
* Add decorator example crate and split off chapter
* Fix ci
* Add empty workspace key
* Try fix ci
* fix ci
* reuse target dir for examples CI
* add pytests folder to makefile recipes
* fix ci, try 2
* add missing pyproject.toml
* remove TOX_TESTENV_PASSENV from Makefile
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
* Add 'anyhow' feature which provides simple From<anyhow::Error> for PyErr impl
This makes it possible to use anyhow::Result<T> as the return type for
methods and functions exposed to Python.
The current implementation just stringifies the anyhow::Error before
shoving it into a PyRuntimeError. Conversion back to the anyhow::Error
is not possible, but it is better than nothing.
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
* Document `anyhow` feature in the guide
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
* update changelog to document anyhow feature
* WIP adding tests
* Finish up anyhow feature
* Fix formatting
* Fix tests
* Fix tests
* Apply review suggestions
Co-authored-by: Bruno Kolenbrander <59372212+mejrs@users.noreply.github.com>
Co-authored-by: mejrs <brunokolenbrander@hotmail.com>
* Clean up doctests, deny some lints
* Apply suggestions from review.
* replace \" with '
* Fix some more doc examples
* Fix formatting
* Fix some more things
* Remove unused parentheses
* Only test class sig on supported abi/platforms
* Only test class signature on correct versions
* Fix tests to compile on msrv
* msrv strikes yet again
* Add feedback
* Pin `half` to 1.7.1 on msrv
* chore: update rust 1.55
* move test to 1.55 only
* make ci happy
* make ci happy
* make ci happy
* make ci happy
* make clippy happy
* make ci happy
* formatting
PR #1856 was buggy in that the `pyo3-build-config` crate didn't actually
work in library mode because `include_str!()` was attempting to resolve
missing files as part of populating some `const` values.
We could change the logic of these constants to make them lazy if
we wanted to support possibly getting access to the value. But the
simple solution is to conditionalize their presence on the crate
feature.
Test coverage for building and testing the crate in insolation with the
feature disabled has been added.
Various code has been conditionalized to avoid compiler warnings.
Also, it appears `cargo build|test -p pyo3-build-config
--no-default-features` still passes default features. This seems wrong
to me. But it is how my system behaves. Maybe it is an sccache bug?
I coded the new tests to `cd pyo3-build-config` first to work around.
dependabot[bot]