Recent commits to derivepassphrase.git (4e800e27ab5b23ab8867bd5d74fdde3243a78833)

Merge topic branch 'fix-notes-test' into master

2025-02-11T18:26:05+01:00

* t/fix-notes-test:
  Fix faulty notes usage test
</pre>

Fix faulty notes usage test

2025-02-11T18:18:41+01:00

The test only ever really acts on the whitespace-trimmed notes, so write
it as such.
</pre>

Merge topic branch 'quality-control-automation' into master

2025-02-10T00:20:26+01:00

* t/quality-control-automation:
  Document the addition of quality control tools in the changelog
  Fix automatic quality control handling of too-long lines
  Fix minor message deviations in the source tree and phrasing in the manpages
  Add message IDs (and missing entries) to the manpage diagnostics listings
  Add quality control scripts
  Prepare `bump-my-version` for this project
  Store the version only in pyproject.toml
</pre>

Document the addition of quality control tools in the changelog

2025-02-10T00:15:57+01:00

</pre>

Fix automatic quality control handling of too-long lines

2025-02-09T22:17:47+01:00

In general, we want the formatter to deal with too-long lines (E501) as
much as possible by itself, and the linter to warn us on E501 lines the
formatter *cannot* deal with.  However, just naively running the linter
and formatter causes the linter to abort on any E501 lines it
encounters, because the linter cannot auto-fix them.  So we want to run
the linter twice, once before the formatter and once after the
formatter, while ignoring E501 violations in the first run.  (But
because E501 noqa markers are now treated as unnecessary noqa markers
during the first linting run, we actually need to ignore both E501 and
RUF100 in the first run.)
</pre>

Fix minor message deviations in the source tree and phrasing in the manpages

2025-02-09T20:58:40+01:00

</pre>

Add message IDs (and missing entries) to the manpage diagnostics listings

2025-02-09T20:47:17+01:00

Using the new quality control scripts, add message IDs to all diagnostic
messages described in the manpages, and add the entries missing from the
manpages as well.
</pre>

Add quality control scripts

2025-02-09T20:47:17+01:00

Add a quality control script `qc_auto.py` that calls the linter, the
formatter, the type checker, the test suite and the documentation
builder, depending on what branch we are on.  It is intended to be
usable as a pre-commit hook.

Add another quality control script `man_diagnostics.py` that checks that
the diagnostics documented in the manpages are complete, and match the
enum values within `derivepassphrase`.  It relies on annotations
(comments) in the manpages to map description texts to the respective
enum values (the mapping is not one-to-one).  It also does
a (rudimentary) check that every warning and error message is mentioned
somewhere in the source tree (besides the messages module that defines
those messages).
</pre>

Prepare `bump-my-version` for this project

2025-02-08T19:58:45+01:00

Prepare and configure the use of `bump-my-version` to automate keeping
version numbers synchronized everywhere.  From a cursory search, this
appears to be the most mature and actively developed tool of this kind
with support for `pyproject.toml` and multiple files with file-specific
replacements.  Some minor warts remain (non-recursive globbing,
duplication of the version number, incorrect calculation of the next
release due to missing true support for pre-release segments), but they
can be worked around, for now.
</pre>

Store the version only in pyproject.toml

2025-02-08T17:24:28+01:00

Establish pyproject.toml functionally as the single source of truth for
the version number, so users can rely on `importlib.metadata.version` to
query the version programmatically [1, 2].  Storing the version number
in the packaging metadata makes it directly accessible to most build
tools statically, instead of dynamically, which in theory would make
certain kinds of operations (reinstall, querying the metadata from a git
checkout) much more tractable [3].  And frankly, the only reason the
version attribute previously was dynamic was incomplete tooling support.
[4, 5]

We still retain the `__version__` attribute -- we need the version
number for the command-line interface and machinery, and querying it via
the installed packages registry is unnecessarily heavyweight -- but only
on the top-level package.  Same goes for the `__author__` attribute.

In future commits, the `__version__` attribute (and version markers in
other files such as the manpages) will be auto-generated by our build
system, commit hooks, or the like.  In general, what we still need is
a system to update all mentions of a version number across the software
package [6].

Further reading:

 1. Python Packaging Authority: [Single-sourcing the Project
    Version](https://packaging.python.org/en/latest/discussions/single-source-version/).
 2. Hynek Schlawek: [Python Packaging
    Metadata](https://hynek.me/articles/packaging-metadata/).
 3. Armin Ronacher: [Constraints are Good: Python's Metadata
    Dilemma](https://lucumr.pocoo.org/2024/11/26/python-packaging-metadata/).
 4. Barry Warsaw: [`hatch version` should be able to handle static
    version numbers](https://github.com/pypa/hatch/issues/1419).
 5. Henry Schreiner: [Support PEP 621
    version?](https://github.com/callowayproject/bump-my-version/issues/66)
 6. Alex Gaynor: [Scaling Software
    Development](https://alexgaynor.net/2020/feb/18/scaling-software-development/).
    "As the scale of a codebase increases, any properties of it which
    are not programmatically enforced will tend to regress."
</pre>