Restore RPM builds from pyproject configuration

[pevogam]

Summary by CodeRabbit

• Chores
  • Updated project version to 1.8.0
  • Refined project configuration and build system setup

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The changes update project build and metadata configuration. In pyproject.toml, the version declaration is changed from dynamic sourcing to an explicit static value of "1.8.0", and the license declaration is converted from a string format to a structured format using {text = "GPL-2.0-or-later"}. In python-aexpect.spec, the Python packaging build and install macros are updated from %py3_build/%py3_install to %pyproject_wheel/%pyproject_install, and the file listing is refactored to use the %{pyproject_files} macro instead of explicit file paths.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Pyproject rpms' is vague and generic, using non-descriptive terms that don't clearly convey what changes are being made to the codebase.	Use a more specific title that describes the main change, such as 'Convert to pyproject.toml-based RPM packaging' or 'Update RPM spec to use pyproject macros'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

pyproject.toml (1)

2-2: Remove setuptools-scm dependency and configuration when using static versioning.

With an explicit static version on line 9, setuptools-scm is no longer needed. Its presence adds unnecessary build complexity and dependency overhead. The [tool.setuptools_scm] configuration (lines 44-46) is now ineffective.

🔎 Proposed fix to remove setuptools-scm

 [build-system]
-requires = ["setuptools>=61.0", "setuptools-scm>=8"]
+requires = ["setuptools>=61.0"]
 build-backend = "setuptools.build_meta"

Also remove the unused configuration section:

-[tool.setuptools_scm]
-version_scheme = "post-release"
-local_scheme = "node-and-date"
-

And from line 36, remove it from dev dependencies:

-dev = ["aexpect[test,lint]", "setuptools-scm>=8", "build", "twine"]
+dev = ["aexpect[test,lint]", "build", "twine"]

Also applies to: 9-9, 44-46

🧹 Nitpick comments (1)

python-aexpect.spec (1)

39-40: Consider using %pyproject_buildrequires for automatic dependency management.

While the current explicit BuildRequires work correctly, the %pyproject_buildrequires macro can automatically generate build dependencies from pyproject.toml, reducing maintenance burden.

🔎 Optional refactor to use %pyproject_buildrequires

 BuildArch: noarch
-BuildRequires: python3-devel
-BuildRequires: python3-setuptools
+BuildRequires: pyproject-rpm-macros
+BuildRequires: python3-devel
+%generate_buildrequires
+%pyproject_buildrequires

This automatically pulls python3-setuptools and other build dependencies from your pyproject.toml.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 02e782c and 262b9a8.

📒 Files selected for processing (2)

• pyproject.toml
• python-aexpect.spec

🔇 Additional comments (3)

python-aexpect.spec (2)

63-63: LGTM! Modern pyproject macros are correctly implemented.

The migration from legacy %py3_build/%py3_install to modern %pyproject_wheel/%pyproject_install/%pyproject_save_files macros is correct and follows current Fedora/RHEL Python packaging guidelines. This approach provides better integration with PEP 517 build systems and automatic file list generation.

Also applies to: 66-67

---

76-76: LGTM! File listing automation improves maintainability.

Using -f %{pyproject_files} automates Python file listing, reducing manual maintenance. Explicit entries for %license, %doc, and binaries remain appropriate.

pyproject.toml (1)

10-10: No changes needed. The pyproject.toml uses the SPDX identifier GPL-2.0-or-later and the .spec file uses the Fedora/RPM identifier GPLv2+ — both correctly represent the same license using their respective ecosystem standards. Using different formats across different packaging systems is standard practice and expected.

Likely an incorrect or invalid review comment.

[pevogam]

I will wait for comments on the approach towards fixed version and why the arguments for it could be wrong before removing the setuptools-scm dependency if ever.