Generate dunder metadata file with __title__
, __author__
, etc. Also tools to discover these in other packages.
pipx install metametameta
Defaults to putting an __about__.py
file in the module directory, assuming your package name is your main module name.
metametameta poetry
Or set everything explicitly:
metametameta poetry --name "something" --source some.toml --output OUTPUT "mod/meta/__meta__.py"
Subcommand per source.
usage: metametameta [-h] {setup_cfg,pep621,poetry,importlib} ...
metametameta: Generate __about__.py from various sources.
positional arguments:
{setup_cfg,pep621,poetry,importlib}
sub-command help
setup_cfg Generate from setup.cfg
pep621 Generate from PEP 621 pyproject.toml
poetry Generate from poetry pyproject.toml
importlib Generate from installed package metadata
options:
-h, --help show this help message and exit
Subcommand help (they all have the same switches)
usage: metametameta poetry [-h] [--name NAME] [--source SOURCE] [--output OUTPUT]
options:
-h, --help show this help message and exit
--name NAME Name of the project (from file if omitted)
--source SOURCE Path to pyproject.toml
--output OUTPUT Output file
TODO: Programmatic interface.
import metametameta as mmm
# not implemented yet
mmm.find_metadata("path/to/module")
There are many modern ways to get metadata about packages, as of 2024, importlib.metadata and it's backports will get you lots of metadata for yours and other packages.
The newest way is PEP-621, see also packaging.python.org
The oldest way to provide metadata was to use dunder variables in your package, e.g. __author__
, __version__
, etc.
The method was never strongly standardized, neither officially nor informally. Here is one early proponent of this sort of metadata.
- Metadata fields can appear in any or no python file in a project.
- Sometimes they are at the top of a single file python module, common locations for metadata:
__init__.py
__meta__.py
__about__.py
- Some metadata elements could reasonably be in every single file.
- There are no particular standards for the type of
__author__
. It could be a string, space delimited string, list or tuple. That is true for the other metadata elements as well. - Sometimes the metadata values are code, e.g.
__version__
could be a string or some tuple or data class representing a version.
On each build, regenerate the __about__.py
. Pick one source of your canonical metadata, e.g. pyproject.toml
,
setup.py
, setup.cfg
.
If you have a lot of packages and you are doing analytics or something with them, you could compile all the metadata as declared in the source code. It could be different from the metadata that shows on the PyPI page. If you are searching for contact info for a package maintainer, this might be useful.
Another marginal use case is in error logging. Error loggers gather up info from just about anywhere, anything can
be a clue including metadata of dependencies. So this is one more source of that. See bug_trail
for a proof of
concept for this usage.
Another marginal use case is that is a folksonomy, a taxonomy created by the people. The official metadata is
governed by the Python Packaging Authority and the Python Software Foundation. If, say, you wanted to add a metadata
item for __mailing_address__
you could easily do it with source code metadata.