Implement conversion between rust_decimal::Decimal and decimal.Decimal
from Python's stdlib. The C API does not appear to be exposed on the
Python side so we need to call into it via Python.
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>
I have a use case in PyOxidizer where I want to use the
pyo3-build-config crate as a library crate so I can access the
`InterpreterConfig` struct so I can read/write config files without
reinventing the wheel.
This is doable before this commit. But it requires that the
build environment have a Python interpreter. This is undesirable
for library usage.
This commit introduces a cargo feature flag to control whether the
build script does anything. The feature flag must be present for
the build script to resolve a config. The feature flag is enabled
by default for backwards compatibility. The pyo3 and pyo3-macros-backend
crates use this feature by default, for backwards compatibility and
because it is the reasonable default.
This is probably room to conditionalize some APIs and other behavior
based on this feature flag. But we stop short of doing that for
the time being.
PyOxidizer has crates depending on `pyo3` that would like to access
the `pyo3` crate configuration. (This use case isn't unique to
PyOxidizer.)
Cargo has a facility for enabling the build scripts of dependent
crates to access _exported_ variables via `DEP_` environment
variables. However, this only works if the exporting crate defines a
`links` key in its Cargo manifest. See
https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key.
While `pyo3`'s build script doesn't yet export the variables that
PyOxidizer will need, a prerequisite to making this work is adding
the `links` key. Since this change could introduce unintended
side-effects, it warrants being made in its own commit, which is
why we're making this change outside of #1793.
I _think_ this change should be mostly safe: the `links` key is
effectively metadata advertising that a crate links against a named
library. The only side-effects setting it has is to enable the
aforementioned `DEP_` environment variables in build scripts and
enforcing a limitation that only a single crate may link against the
same native library. I believe the only potential for this change
to cause problems is if there are multiple crates with `links =
"python"` entries. I'm not aware of any other crates that advertise
`links = "python"`: even `python3-sys` / `cpython` use `links =
"python3"` so this change should not prevent dual use of `pyo3` and
`cpython` in the same build.
When building an extension with rust-numpy and ndarray on the MSRV of
1.41 with complex numbers. The num-complex crate version needs to be
0.2 which was the pinned version as of ndarray 0.13.1 which was the last
release of ndarray that supported building with rust 1.41. However, the
pyo3 pinned version of 0.4 is incompatible with this and will cause an
error when building because of the version mismatch. To fix this This
commit expands the supported versions for num-complex to match what
rust-numpy uses [1] so that we can build pyo3, numpy, ndarray, and
num-complex in an extension with rust 1.41.
Fixes#1798
[1] https://github.com/PyO3/rust-numpy/blob/v0.14.1/Cargo.toml#L19
David Hewitt