https://git.schokokeks.org/derivepassphrase.git/tree/947a212e444c7ccf03c5005b9ba270e9549794f2 Recent commits feed provided by GitList. 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 https://git.schokokeks.org/derivepassphrase.git/commit/f81c616548e53fe088636bf9eb6fbaf7873c8c25 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 19:09:54 +0100 f81c616548e53fe088636bf9eb6fbaf7873c8c25 * t/readable-json-dump: Document the change in JSON formatting GitHub: Closes #20. https://git.schokokeks.org/derivepassphrase.git/commit/b05668d5614d47158c8f8f0ef5145775d5ee40d8 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 18:17:59 +0100 b05668d5614d47158c8f8f0ef5145775d5ee40d8 Although, having since also written up the motivation for this change in the issue tracker, I'm somewhat less convinced of how sensible this change is (in parts) in the long run. https://git.schokokeks.org/derivepassphrase.git/commit/9c8e7ecd02fd53473ea6d09504cd07555e417fb6 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 18:00:55 +0100 9c8e7ecd02fd53473ea6d09504cd07555e417fb6 When deriving a passphrase, if the service has any notes, vault(1) prints the notes after the passphrase. However, akin to source code comments before the code in question, service notes may actually be better placed above the derived passphrase instead, for some types of notes. Support such placement via a new command-line option `--print-notes-before`; the default, vault(1)-compatible behavior can be explicitly selected via `--print-notes-after`. https://git.schokokeks.org/derivepassphrase.git/commit/c6a84c41a8c866b8f0467b5772a62515e7fcf3b9 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 16:01:14 +0100 c6a84c41a8c866b8f0467b5772a62515e7fcf3b9