https://git.schokokeks.org/derivepassphrase.git/tree/dacf79e57cd521ca9489148bda95fc0a53229ca5 Recent commits feed provided by GitList. 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 Update the manpages to include the corrected and extended handling of the `--notes` config option. That is, document the `--modern-editor-interface` and `--vault-legacy-editor-interface` options, and the new warning messages about `--notes` requiring `--config` and that a backup copy of the notes have been made. Some minor adjustments to the vault(1) legacy editor interface warning messages were made to ease inclusion in the manpage while making the intent clear. Additionally, derivepassphrase with the legacy interface correctly fills in the old notes contents if any, instead of unconditionally filling in the placeholder text. https://git.schokokeks.org/derivepassphrase.git/commit/18e1bf52dbb2b0ea4e3c1eeb9c400429b1bbe756 software@the13thletter.info (Marco Ricci) Fri, 07 Feb 2025 15:19:22 +0100 18e1bf52dbb2b0ea4e3c1eeb9c400429b1bbe756 Reintroduce the previous git-like editor interface as the "modern" editor interface to the "vault" subcommand, and provide explicit options `--modern-editor-interface` and `--vault-legacy-editor-interface`, defaulting to the latter for compatibility. Furthermore, for the legacy interface, introduce a backup copy of the notes to guard against accidental data loss, because the legacy interface offers no way to abort mid-editing, making fatal mistakes all the more likely. https://git.schokokeks.org/derivepassphrase.git/commit/61fbc909d899ac2bd791b14c20987553b638ac4f software@the13thletter.info (Marco Ricci) Thu, 06 Feb 2025 14:27:21 +0100 61fbc909d899ac2bd791b14c20987553b638ac4f In 7b0f4e121a5e688b59abad73b8b60bacfc7d02ed, we adjusted `derivepassphrase` to only act upon `--notes` if `--config` is also given, for compatibility with vault(1). However, this is incompatible with previous versions of `derivepassphrase`, and potentially confusing even to vault(1) users. As such, `derivepassphrase vault` now emits a warning if it is called with `--notes` but without `--config`. https://git.schokokeks.org/derivepassphrase.git/commit/4db75cd458b8c16baba9def7cbdc8d917fe0e017 software@the13thletter.info (Marco Ricci) Thu, 06 Feb 2025 13:16:37 +0100 4db75cd458b8c16baba9def7cbdc8d917fe0e017 We originally provided a modern git-like editor interface, with a marker for explanatory texts and with support for aborting the edit by leaving the file empty. vault(1) however takes the contents of the notes file literally. For compatibility, we must do the same. https://git.schokokeks.org/derivepassphrase.git/commit/7b67d930b8166f6fa1b68dca568134f5d31e4b10 software@the13thletter.info (Marco Ricci) Wed, 05 Feb 2025 14:44:16 +0100 7b67d930b8166f6fa1b68dca568134f5d31e4b10