Recent commits to derivepassphrase.git (06fc8a12e108f2d64985a8e458585515de3ed81d)

Add an option filter for short options and option aliases

2026-08-16T16:09:04+02:00

</pre>

Add parser stages for the planned new command-line argument parser

2026-08-16T16:05:46+02:00

These are the actual parser steps.  They must be run in sequence, and
generally only act on the current "section" of the command-line (up to
the next subcommand boundary).

  - The first step normalizes the command-line, inserting the `--`
    pseudo-option, unclustering clustered options, using canonical
    option and subcommand names, and appending option arguments to the
    argument in `--opt=arg` style.  This step relies on the `canon_map`
    property of CLISubcommand objects.

  - The second step scans for eager options, if necessary replacing the
    whole command-line with the eager option.  This step too relies on
    the `canon_map` property of CLISubcommand objects.

  - The third step locates the subcommand boundary, if any, and returns
    the partial command-line up to that boundary, and a new parser state
    for the remaining section.  This step too relies on the `canon_map`
    property of CLISubcommand objects.

  - An additional "complete" step calls the first three steps, in order,
    on each section of the command-line, and returns the accumulated
    results.  This step relies on the `canon_map` property of
    CLISubcommand objects, indirectly, via the first three steps.
</pre>

Add a canon_map property to the CLISubcommand classes

2026-08-16T15:37:05+02:00

The canonical map of option or subcommand names maps such a name to the
respective option or subcommand object.  It is a dependent attribute
(and thus should be excluded from `__init__`, `__eq__` and `__lt__`,
etc.) and somewhat expensive to compute, so we cache the result in
a global weak key dictionary, because the subcommand objects themselves
are immutable.
</pre>

Add data structures for the planned new command-line argument parser

2026-08-16T15:36:09+02:00

The command-line interface is organized as a hierarchy of "subcommand"
objects, which contain "option group" objects, which contain "option"
objects.  The parser is multi-stage, and has an explicit "state" object
containing the top-level subcommand specification and the command-line
to parse.  The parser steps are monadic, similar to the "Maybe" monad:
each step depends only on the current state, and returns a ParseFailure
or ParseEarlyExit state (which skips any further computation), or
a ParseSuccess state (which does not).

This commit only contains the data structures, not the actual parser
steps.
</pre>

Add new help text messages with option specs and metavars expanded inline

2026-08-16T09:20:06+02:00

For all option one-line descriptions, add variants where the option
specification (as it appears in the help text) is included inline, as
a first line/first paragraph, and the one-line description as the second
paragraph.  In these variants, metavars are expanded inline, as in the
previous commit.

The inline expansion of metavars follows the reasoning from the previous
commit.  The one-line description is due to a planned new command-line
argument parser, which is strictly a parser and thus leaves option
grouping, mutually exclusive options and help text generation to the
application.  Keeping the formatted option specification in the help
text string gives the translators more context, and also allows the
application (the help text formatting part at least) to rediscover the
grouping or mutual exclusivity based on identical help text strings.
</pre>

Add new help and error messages with metavars expanded inline

2026-08-16T08:52:13+02:00

For all texts that aren't one-line option descriptions, add versions of
the text where the metavar is expanded inline, instead of referencing
a different translation string inline.  If multiple texts need to use
the same metavar consistently, pick one of them, and reference that
canonical entry in the other entries' commentary.

This is partly based on search engine/AI feedback on how other projects
solve the problem of wanting to explain mini-formats or other
conventions common to multiple messages to translators: there is no
place to put (machine-readable) references or common explanation, so it
is typical instead to refer inline in the translation commentary to
a canonical entry that contains longer-form explanation instead.  This
is rather awkward to work with if there are multiple layers of expansion
(metavars) in the messages, so it is probably easier on the translators
to include the metavar inline and just note that "canonical text X" uses
the same metavar.  Of course, the canonical text should be short enough
to be easily included inline in the commentary.
</pre>

Update wishlist to post-v0.6.1

2026-07-06T21:29:46+02:00

</pre>

Release 0.6.1

2026-07-06T21:28:06+02:00

</pre>

Merge branch 'release-0.6.1-preparations'

2026-07-06T21:20:40+02:00

Prepare to release derivepassphrase v0.6.1

* release-0.6.1-preparations:
  Update wishlist
  Update the translation template, the German translation, and the message catalogs
  Add changelog entries for economic-test-suite, click-8.4.2-compatibility and openssh-bug3967-workaround
  Reformat everything with ruff
  Update wishlist
  Set the Python path correctly during pytest invocation
</pre>

Update wishlist

2026-07-06T20:19:03+02:00

Also reference the new entry in the changelog.
</pre>