https://git.schokokeks.org/derivepassphrase.git/tree/fb7d17d3c5629869cae528ce72f80dca4f433acf Recent commits feed provided by GitList. When using `pipx` to install `derivepassphrase`, `pipx` will now correctly locate the `derivepassphrase` manpages and make them available to the user. https://git.schokokeks.org/derivepassphrase.git/commit/fb7d17d3c5629869cae528ce72f80dca4f433acf software@the13thletter.info (Marco Ricci) Tue, 11 Feb 2025 00:57:53 +0100 fb7d17d3c5629869cae528ce72f80dca4f433acf * 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 https://git.schokokeks.org/derivepassphrase.git/commit/6eed9899514c22872a8663e3e3016329f0f1a723 software@the13thletter.info (Marco Ricci) Mon, 10 Feb 2025 00:20:26 +0100 6eed9899514c22872a8663e3e3016329f0f1a723 https://git.schokokeks.org/derivepassphrase.git/commit/b07a5d00772ffb89628ab3ce8d251eaef76a01f1 software@the13thletter.info (Marco Ricci) Mon, 10 Feb 2025 00:15:57 +0100 b07a5d00772ffb89628ab3ce8d251eaef76a01f1 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.) https://git.schokokeks.org/derivepassphrase.git/commit/09205797f62a19bf3f7dd9f203cf10f6b541e0ee software@the13thletter.info (Marco Ricci) Sun, 09 Feb 2025 22:17:47 +0100 09205797f62a19bf3f7dd9f203cf10f6b541e0ee https://git.schokokeks.org/derivepassphrase.git/commit/947a212e444c7ccf03c5005b9ba270e9549794f2 software@the13thletter.info (Marco Ricci) Sun, 09 Feb 2025 20:58:40 +0100 947a212e444c7ccf03c5005b9ba270e9549794f2 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. https://git.schokokeks.org/derivepassphrase.git/commit/47322731c63f9323de73c468671f1ab77f21ee7e software@the13thletter.info (Marco Ricci) Sun, 09 Feb 2025 20:47:17 +0100 47322731c63f9323de73c468671f1ab77f21ee7e 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). https://git.schokokeks.org/derivepassphrase.git/commit/7ad6f085929dbe15d25b9e1885948fdfc752c1ee software@the13thletter.info (Marco Ricci) Sun, 09 Feb 2025 20:47:17 +0100 7ad6f085929dbe15d25b9e1885948fdfc752c1ee 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. https://git.schokokeks.org/derivepassphrase.git/commit/4aa3f0c0ecf1adc4e3907c7db1ecd6602a100b58 software@the13thletter.info (Marco Ricci) Sat, 08 Feb 2025 19:58:45 +0100 4aa3f0c0ecf1adc4e3907c7db1ecd6602a100b58 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." https://git.schokokeks.org/derivepassphrase.git/commit/dacf79e57cd521ca9489148bda95fc0a53229ca5 software@the13thletter.info (Marco Ricci) Sat, 08 Feb 2025 17:24:28 +0100 dacf79e57cd521ca9489148bda95fc0a53229ca5 * t/notes-handling: Document recent changes to notes handling in the changelog Optionally support printing vault service notes before the passphrase Document the modern editor interface Reintroduce a "modern" editor interface à la git-commit or git-rebase Warn the user when `derivepassphrase vault --notes` is ineffective Use a vault(1)-compatible naive notes editing system Use hypothesis for notes handling tests Adapt notes printing test to arbitrary notes Clean up notes testing functions Use a better test for no-op editing notes Partially align notes printing and editing behavior with vault(1) Assert that notes should be printed (via xfailing test) GitHub: Closes #18, closes #19. https://git.schokokeks.org/derivepassphrase.git/commit/9b5805eb652e97ee4b63f6afbcf9563aba3311f0 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 19:19:19 +0100 9b5805eb652e97ee4b63f6afbcf9563aba3311f0