Recent commits to derivepassphrase.git (dacf79e57cd521ca9489148bda95fc0a53229ca5)

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>

Merge topic branch 'notes-handling' into master

2025-02-07T19:19:19+01:00

* 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.
</pre>

Document recent changes to notes handling in the changelog

2025-02-07T19:09:54+01:00

</pre>

Merge topic branch 'readable-json-dump' into master

2025-02-07T18:17:59+01:00

* t/readable-json-dump:
  Document the change in JSON formatting

GitHub: Closes #20.
</pre>

Document the change in JSON formatting

2025-02-07T18:00:55+01:00

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.
</pre>

Optionally support printing vault service notes before the passphrase

2025-02-07T16:01:14+01:00

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`.
</pre>

Document the modern editor interface

2025-02-07T15:19:22+01:00

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.
</pre>

Reintroduce a "modern" editor interface à la git-commit or git-rebase

2025-02-06T14:27:21+01:00

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.
</pre>

Warn the user when `derivepassphrase vault --notes` is ineffective

2025-02-06T13:16:37+01:00

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`.
</pre>

Use a vault(1)-compatible naive notes editing system

2025-02-05T14:44:16+01:00

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.
</pre>