fix an issue for building

[phenobarbital]

Summary by Sourcery

Modernize package build and metadata configuration to rely on pyproject.toml instead of setup.py-driven metadata, and bump the library version.

New Features:

• Define project metadata, dependencies, and URLs using the PEP 621 [project] table in pyproject.toml.
• Configure setuptools package data for Cython and Rust-related modules via pyproject.toml.

Enhancements:

• Relax and update build-system requirements, adding setuptools_scm-based dynamic versioning and pip to the build dependencies.
• Streamline setup.py to only handle Cython and Rust extension building, delegating metadata and dependency management to pyproject.toml.
• Update pytest configuration to define test discovery patterns, strict settings, and asyncio marker usage in pyproject.toml.

Build:

• Switch to setuptools.build_meta with PEP 621 metadata and dynamic version configuration using datamodel.version.version.
• Add uv override configuration for setuptools-rust and remove legacy cibuildwheel and flit configuration.

Documentation:

• Link project documentation and funding URLs under the [project.urls] section in pyproject.toml.

Chores:

• Bump the package version from 0.10.19 to 0.10.20.

[sourcery-ai]

Reviewer's Guide

Modernizes the packaging and build configuration by moving metadata and dependencies into pyproject.toml using PEP 621, simplifying setup.py to only handle compiled extensions, adjusting test tooling configuration, and bumping the package version.

Sequence diagram for building the package with modernized configuration

sequenceDiagram
    participant Dev as Developer
    participant Pip as pip
    participant SB as setuptools_build_meta
    participant CY as Cython
    participant SR as setuptools_rust

    Dev->>Pip: pip wheel .
    Pip->>SB: Read pyproject.toml
    SB-->>Pip: Build requirements
    Pip->>Pip: Install build deps
    Pip->>SB: Invoke build_wheel

    SB->>SB: Load project metadata
    SB->>CY: cythonize extensions
    CY-->>SB: Compiled C sources

    SB->>SR: Build Rust extensions
    SR-->>SB: Compiled Rust artifacts

    SB-->>Pip: Built wheel
    Pip-->>Dev: Wheel file in dist/

Loading

Flow diagram for new build and test workflow using pyproject.toml

flowchart TD
    A[Start] --> B[Edit source code and datamodel.version]
    B --> C[Define metadata and dependencies in pyproject.toml
project section]
    C --> D[Configure build-system
setuptools.build_meta
and build requirements]
    D --> E[Configure extensions in setup.py
Cython and Rust extensions only]
    E --> F[Build package
python -m build / pip wheel]
    F --> G[setuptools.build_meta reads pyproject.toml
and setup.py]
    G --> H[Compile Cython extensions
via cythonize]
    H --> I[Build Rust extensions
via setuptools_rust]
    I --> J[Produce wheel and sdist]
    J --> K[Run tests with pytest
using tool.pytest.ini_options]
    K --> L[Optional: manage deps with uv
override setuptools-rust]
    L --> M[End]

Loading

File-Level Changes

Change	Details	Files
Migrate project metadata and runtime dependencies from flit/setuptools setup.py into PEP 621-style [project] configuration in pyproject.toml.	Replace deprecated [tool.flit.metadata] section with a [project] table including name, dynamic version, description, authors, readme, license, keywords, classifiers, and URLs. Move install_requires/runtime dependencies into [project.dependencies] with explicit pinned or minimum versions. Add [project.urls] entries for homepage, source, tracker, documentation, funding, and thanks links.	pyproject.toml
Update build-system requirements and setuptools configuration to support modern PEP 517 builds with Cython and Rust extensions.	Loosen and extend build-system requires to minimum versions for setuptools, wheel, setuptools-rust, and add setuptools_scm[toml] and pip. Add [tool.setuptools] configuration for license files, packages, and include-package-data. Define [tool.setuptools.package-data] for Cython/PXD resources and [tool.setuptools.dynamic] to derive version from datamodel.version.version. Add [tool.uv.override-dependencies] to pin/override setuptools-rust in uv-based workflows.	pyproject.toml
Reconfigure pytest settings directly in pyproject.toml and simplify warning handling and markers.	Re-add [tool.pytest.ini_options] with strict config/markers and CLI logging options. Define test discovery options (testpaths, python_files, python_functions). Simplify filterwarnings to treat all warnings as errors and declare an asyncio marker for pytest-asyncio tests.	pyproject.toml
Simplify setup.py to delegate package metadata and dependencies to pyproject.toml, keeping only compiled extension configuration.	Remove custom version/metadata parsing from datamodel/version.py and use of readme() helper for long_description. Drop packaging metadata arguments (name, version, author, classifiers, install_requires, setup_requires, project_urls) and package discovery from setup(). Retain only ext_modules via cythonize(), rust_extensions, and zip_safe settings in setup(). Remove unused imports such as ast, path utilities, find_packages, and find_namespace_packages.	setup.py
Bump internal package version to reflect the new build configuration.	Increment version from 0.10.19 to 0.10.20 in datamodel.version module.	datamodel/version.py

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 2 issues, and left some high level feedback:

• Using packages = ["datamodel"] in [tool.setuptools] will exclude nested subpackages (e.g. datamodel.rs_parsers, datamodel.libs.*); consider switching to packages = setuptools.find_namespace_packages(...) or find_packages() configuration to ensure all modules are included in the wheel.
• Adding pip>=24.3.1 to [build-system].requires can cause unnecessary bootstrap/circular dependency issues in build environments; it’s usually better to rely on the frontend’s pip and keep only actual build backends and plugins in this list.
• Now that you’ve centralized install requirements in [project.dependencies], the setup.py no longer declares install_requires; to avoid divergence if both build paths are used, consider either delegating entirely to pyproject-based builds or making setup.py read from the same source of dependency metadata.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Using `packages = ["datamodel"]` in `[tool.setuptools]` will exclude nested subpackages (e.g. `datamodel.rs_parsers`, `datamodel.libs.*`); consider switching to `packages = setuptools.find_namespace_packages(...)` or `find_packages()` configuration to ensure all modules are included in the wheel.
- Adding `pip>=24.3.1` to `[build-system].requires` can cause unnecessary bootstrap/circular dependency issues in build environments; it’s usually better to rely on the frontend’s pip and keep only actual build backends and plugins in this list.
- Now that you’ve centralized install requirements in `[project.dependencies]`, the `setup.py` no longer declares `install_requires`; to avoid divergence if both build paths are used, consider either delegating entirely to pyproject-based builds or making `setup.py` read from the same source of dependency metadata.

## Individual Comments

### Comment 1
<location> `pyproject.toml:46` </location>
<code_context>
+dependencies = [
+    "numpy>=1.26.4",
+    "uvloop>=0.21.0",
+    "asyncio==3.4.3",
+    "faust-cchardet==2.1.19",
+    "ciso8601==2.3.2",
</code_context>

<issue_to_address>
**issue (bug_risk):** Pinning `asyncio` from PyPI conflicts with the stdlib `asyncio` on Python ≥3.10.

Given `requires-python = ">=3.10.0"`, `asyncio` should come from the standard library; the PyPI `asyncio` package is a legacy backport. Pinning `asyncio==3.4.3` risks shadowing the stdlib module and causing subtle runtime issues. Please remove this dependency and rely on the stdlib version, or, if the backport is truly required, document the rationale and ensure it cannot override the built-in module on supported platforms.
</issue_to_address>

### Comment 2
<location> `pyproject.toml:69` </location>
<code_context>
+
+[tool.setuptools]
+license-files = ["LICENSE"]
+packages = ["datamodel"]
+include-package-data = true
+
</code_context>

<issue_to_address>
**suggestion (bug_risk):** Hardcoding `packages = ["datamodel"]` may omit nested subpackages that were previously auto-discovered.

Previously `find_namespace_packages` in `setup.py` auto-discovered all subpackages under `datamodel` (e.g. `datamodel.rs_parsers`, `datamodel.libs.*`). With `packages = ["datamodel"]`, those subpackages may no longer be included in the wheel/sdist unless configured elsewhere. If you intend to ship the entire tree, prefer a `setuptools.packages.find` configuration (e.g. `[tool.setuptools.packages.find]`) over a single hardcoded package name.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[sourcery-ai]

issue (bug_risk): Pinning asyncio from PyPI conflicts with the stdlib asyncio on Python ≥3.10.

Given requires-python = ">=3.10.0", asyncio should come from the standard library; the PyPI asyncio package is a legacy backport. Pinning asyncio==3.4.3 risks shadowing the stdlib module and causing subtle runtime issues. Please remove this dependency and rely on the stdlib version, or, if the backport is truly required, document the rationale and ensure it cannot override the built-in module on supported platforms.

[sourcery-ai]

suggestion (bug_risk): Hardcoding packages = ["datamodel"] may omit nested subpackages that were previously auto-discovered.

Previously find_namespace_packages in setup.py auto-discovered all subpackages under datamodel (e.g. datamodel.rs_parsers, datamodel.libs.*). With packages = ["datamodel"], those subpackages may no longer be included in the wheel/sdist unless configured elsewhere. If you intend to ship the entire tree, prefer a setuptools.packages.find configuration (e.g. [tool.setuptools.packages.find]) over a single hardcoded package name.