Support compiling portable "abi3" extension modules even when
the build host Python interpreter configuration is not available
or the discovered Python interpreter version is not supported.
Maturin already implements this by building "abi3" extension wheels
with `PYO3_NO_PYTHON` environment veriable set for cargo when
an `abi3-py3*` feature is detected.
Closes#2292
Automatically generate `python3.dll` import libraries for Windows
compile targets in the build script.
Adds a new PyO3 crate feature `generate-abi3-import-lib` enabling
automatic import library generation.
Closes#2231
Python 3.6 and older are not supported by the current PyO3 version,
so the removed interpreter version check was a no-op.
`pyo3_build_config::get()` attempts to read a config file from disk
when PyO3 is cross-compiling, which is probably bad for rust-analyzer
and other IDEs that attempt to sandbox the proc macro code.
Instead of a fake build dependency, move the links key from pyo3 to pyo3-ffi
which according to [1] is a prerequisite for build scripts to emit meta-data
that can be used by other build scripts which would incidentally ensure the
ordering between the build script of pyo3 and pyo3-ffi that we need.
[1] https://doc.rust-lang.org/cargo/reference/build-script-examples.html#using-another-sys-crate
* 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>
In particular, distinguish optional crates between those
that are necessary for some named feature (e.g. macros),
and those that can be activated as their own feature
(e.g. anyhow).
* 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>
