Python wrapper: migrate from pybind11 to nanobind + scikit-build-core - #1109

When building from the top-level repo with -DZXING_PYTHON_MODULE=ON,
the root zxing.cmake is already included, making the macro available.
Bare find_package(nanobind CONFIG REQUIRED) had no FetchContent fallback.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Restore find_package(Python ...) needed by nanobind in CMakeLists.txt.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- throw nb::python_error() after raise_from instead of re-throwing the
  original exception (which discarded the chained TypeError)
- wrap post-validation code in try-catch so Py_buffer is always released
  even if narrow_cast or ReadBarcodes throws
- add nb::keep_alive<0,1>() on ImageView.__init__ to keep the caller's
  buffer object alive for the ImageView's lifetime

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…rcodes

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Move zxing.cpp into zxingcpp/ package directory, rename C extension
to _zxingcpp_core, add __init__.py and py.typed for PEP 561 compliance,
and use nanobind_add_stub for .pyi generation at build time.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…sdist

Add the nanobind-generated type stub to the source tree so editors and
type checkers work without a build step. Include it in sdist.include so
it is shipped in source distributions as well.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- Fix sdist.include paths (relative to pyproject.toml, not repo root)
- Remove module-scope `None: ErrorType` alias from stub (Python keyword)
- Skip zxing.cmake include when SKBUILD is set; use find_package(nanobind)
  directly instead, since scikit-build-core installs nanobind from
  build-system.requires before invoking CMake

The sdist -> wheel path was previously broken because:
1. sdist.include paths had wrong wrappers/python/ prefix
2. zxing.cmake is a symlink preserved as-is in the sdist, so
   zxing_add_package was unavailable in isolated builds

Note: zint/backend/ is not in the sdist (pre-existing limitation); wheel
builds from sdist require -DZXING_WRITERS=OFF or a separate zint source.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Python 3.13's tarfile.data_filter rejects symlinks that resolve outside
the extraction directory. The sdist contained two such symlinks:

- LICENSE (-> ../../LICENSE): excluded via sdist.exclude in pyproject.toml;
  wheel builds from the git tree still get the file via wheel.license-files.
- zxing.cmake (-> ../../zxing.cmake): excluded via sdist.exclude; not needed
  in scikit-build-core (SKBUILD) builds since find_package(nanobind) is used
  directly.

The libzint sources were missing from the sdist because zint is a git
submodule (not enumerated by git ls-files). Add wrappers/python/zint ->
../../zint mirroring the existing core/ symlink so MANIFEST.in's
graft zint/backend can follow it on the filesystem and include the 626
backend files needed to compile the writer backend.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…d setup

Hoist the duplicated find_package(Python) and nanobind discovery out of
the hasParent if/else in CMakeLists.txt so the SKBUILD-vs-zxing_add_package
choice is expressed once. Extract make_reader_options, make_writer_options,
and barcode_from_content helpers in zxing.cpp to remove the four-way
ReaderOptions duplication, two-way WriterOptions duplication, and the
str/bytes content dispatch shared between create_barcode and write_barcode.
All 21 wrapper tests still pass.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

When ZXing is built as a shared library (BUILD_SHARED_LIBS=ON), the stub
generator cannot import _zxingcpp_core because ZXing.dll is not on PATH
for the custom build command. Standalone and scikit-build-core builds
default to static linking and are not affected.

Guard nanobind_add_stub with `if (NOT hasParent OR SKBUILD)` so it only
runs in contexts where the DLL is either absent or findable. Always
install the checked-in source-tree stub regardless.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…alization

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…afety

The reader paths (ReadBarcodes via buffer protocol, ImageView, and ndarray
fast-path) already released the GIL before this change. Add matching
gil_scoped_release guards to write_barcode_to_image() and
write_barcode_to_svg() so Python threads are not blocked during
CPU-bound encoding. All Python object construction and PyBuffer calls
remain inside the GIL.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ode/read_barcodes stub signatures

Before this change the stub emitted two @overload entries per function --
one with NDArray[numpy.uint8] (ndarray fast-path) and one with plain
object (buffer/PIL path).  The result was confusing to both type checkers
and IDE autocompletion.

nb::sig() is now applied to all four .def() registrations, giving every
overload the same explicit union type:

    NDArray[numpy.uint8] | PIL.Image.Image | ImageView

A nanobind stub-generator pattern file (stubs.pats) then collapses the
two identical @overload entries for each function into a single
non-overloaded signature, preserving the full docstring via \doc.  This
produces a clean, accurate, single-entry stub for both read_barcode and
read_barcodes.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>