Is your feature request related to a problem? Please describe.
The releaser tool currently detects Python packages by the presence of setup.py and reads the version from a VERSION tuple in the package's __init__.py (or version.py). Modern Python projects are increasingly adopting pyproject.toml as the single source of truth for metadata, often using it to define project metadata and version via PEP 621 (e.g., [project] version = "x.y.z"). The releaser does not currently support this setup.
Describe the solution you'd like
It would be nice to extend the releaser to support Python projects that use pyproject.toml for their build configuration and version declaration.
Describe alternatives you've considered
This is an open-ended idea meant to start a discussion. Contributors are encouraged to think about:
- How should version recognition work for
pyproject.toml-based projects? Should the releaser parse the version field from [project] in pyproject.toml, or look for a dynamic version reference?
- How would version bumping work: would the releaser update the version string directly in
pyproject.toml?
- Would it be possible (and should we) preserve the current pattern used by OpenWISP modules where the canonical version is defined as a
VERSION tuple in __init__.py and then referenced dynamically in pyproject.toml (e.g., via setuptools dynamic versioning)? If so, how would the releaser detect and bump the version in __init__.py?
Additional context
The relevant code is in openwisp_utils/releaser/config.py (package type detection via get_package_type_from_setup(), Python version detection via _handle_python_version()) and openwisp_utils/releaser/version.py (version bumping via _bump_python_version()).
Is your feature request related to a problem? Please describe.
The releaser tool currently detects Python packages by the presence of
setup.pyand reads the version from aVERSIONtuple in the package's__init__.py(orversion.py). Modern Python projects are increasingly adoptingpyproject.tomlas the single source of truth for metadata, often using it to define project metadata and version via PEP 621 (e.g.,[project] version = "x.y.z"). The releaser does not currently support this setup.Describe the solution you'd like
It would be nice to extend the releaser to support Python projects that use
pyproject.tomlfor their build configuration and version declaration.Describe alternatives you've considered
This is an open-ended idea meant to start a discussion. Contributors are encouraged to think about:
pyproject.toml-based projects? Should the releaser parse theversionfield from[project]inpyproject.toml, or look for a dynamic version reference?pyproject.toml?VERSIONtuple in__init__.pyand then referenced dynamically inpyproject.toml(e.g., viasetuptoolsdynamic versioning)? If so, how would the releaser detect and bump the version in__init__.py?Additional context
The relevant code is in
openwisp_utils/releaser/config.py(package type detection viaget_package_type_from_setup(), Python version detection via_handle_python_version()) andopenwisp_utils/releaser/version.py(version bumping via_bump_python_version()).