Use poetry for project tooling. Deprecate module metadata. #31
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The __vars__ module contains dundered variables that are either (a) module-level metadata like '__version__' or (b) static API endpoint URLs. Condense the codebase by moving the metadata into the package __init__ and the API endpoints into the api_urls module. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
Python community tooling generally assumes that module `__author__` and `__email__` dunders are simple strings, rather than sets or lists. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
The project currently uses setuptools, build, and twine to coordinate project build and publishing steps. And it leaves the business of managing the python environment as an exercise to the user. Further, the current setuptools pyproject implementation does not correctly handle Maintainership contact information, and the python dependencies are slightly messed up. We should instead use poetry - which is a modern build tool for python that most of our dependencies use - to manage the python venv and coordinate dependencies. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
The sphinx linkcheck "builder" validates that documentation hyperlinks (anchors) are not broken. Use this facility within the `lint` make target. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
Add a unit test module which validates package metadata. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
The modern (post-PEP440) standard for distributing package metadata is to make use of the package PKG-INFO file and the importlib.metadata standard module. Remove the obsolete module-level __author__ and __version__ dunders, along with the rule34Py.version() method, in favor of the package metadata. Add a new guide, explaining to users how to extract the metadata. Signed-off-by: Riparian Commit <ripariancommit@protonmail.com>
ripariancommit
commented
Jun 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patchset is the result of having to pull a long thread of changes. It started by attempting to deprecate the
__vars__.pysubmodule, which meant moving the package metadata__authors__and__version__info into the module__init__.py. Then I took a closer look at what the modern recommendations are for representing package metadata and eventually decided that our existing pyproject.toml implementation based on setuptools is outdated and insufficient. Instead, this patchset updates the project to use poetry as the project build tool and addresses all of the fallout from that change.Changes
__vars__.pysubmodule has been removed and its content distributed to the other modules that use it (basically just that__base_url__and__api_url__are now inapi_urls.py.pyproject.tomlhas been rewritten to use poetry as the build backend. In the process, I corrected some of the debatebly incorrectAuthorsand dependency information we had before.b3yc0d3and his email as the projectAuthorandMaintainer. I think that is the most correct thing to do. But standard practices here are all over the place in the python world.LICENSEandNOTICE.mdfiles are still in the wheel and source distributions.pyproject.tomlfile. Everywhere else derives their values from it.Makefileimplementation to use poetry as the canonical build tooling. Updated the developer documentation with the steps to use it.importlibto extract the package ownership and version information. AFAICT, this is the "modern" way to extract package metadata, post-PEP-440.rule34Py.rule34Py.version()method, which has been deprecated for a while.linkcheck, that runs the built-in python link checker on the documentation. Fixed up some linting errors that it reported. Added this target to thelintmake target.Notes
pyproject.tomlcontains fewer "Classifiers" than it did previously. That's because poetry automatically adds classifiers for your license and supported python versions. I validated that the final classifiers are correct.publishtarget to use poetry, which has a workflow to upload content to PyPI, just like Twine. If you would like to continue using Twine, we can revert this part. But I would recommend you give poetry a shot.Testing
New METADATA file.
Process