Recent commits to derivepassphrase.git (493fe930240feade37cec6aef097a9740cea550e)

Split off "heavy duty" tests from the respective test file

2025-08-09T14:44:43+02:00

Split off the slow, `hypothesis`-based integration tests (the "heavy
duty" tests) from the `test_derivepassphrase_cli`,
`test_derivepassphrase_ssh_agent` and `test_derivepassphrase_types`
modules into separate submodules named `heavy_duty`.  Additionally, mark
the contents of these `heavy_duty` submodules with the `heavy_duty`
`pytest` mark.

We do this both because the integration tests are slow and because they
are relatively large per test: you typically write a whole new class
plus support code per test, plus you reexport one of the class's
attributes as a top-level, auto-discoverable test.

Though specifically marked, the tests are still run by default.
</pre>

Turn the `vault` test config functions into methods

2025-08-08T23:09:22+02:00

Turn the `is_valid_test_config`, `is_smudgable_vault_test_config` and
`_test_config_ids` functions into methods of the `VaultTestConfig`
class: `is_valid`, `is_smudgable` and `_test_id`.  This fits the overall
intent of only providing types and some simple predicates or
transformations, and it reads much nicer if a short method name is used
instead of an explicit function name.  (And if a one-argument function
is required, it can be obtained, as a bound method, from the class.)
</pre>

Reformat tests after refactoring

2025-08-08T22:58:55+02:00

</pre>

Split the top-level `tests` module into subpackages

2025-08-08T22:58:18+02:00

Split the top-level `tests` module into a pair of subpackages
`tests.data` and `tests.machinery`, grouping them by import
requirements.  This "stratifies" the data, and (in some cases) reduces
the amount of necessary support code while also (always) forcing us to
carefully consider the scope and the prerequisites of every test support
datum or function.

As a practical example of the benefits of this stratification, the
`test_key_signatures_and_outputs.py` script can get away with importing
only the lowest stratum `tests.data`, and thus does not need `pytest` or
`hypothesis` installed to run.

There are five strata, defined by the five subordinate modules in the
`tests` package: `tests.data`, `tests.data.callables`,
`tests.machinery`, `tests.machinery.pytest` and
`tests.machinery.hypothesis`.  Each module may import from modules
earlier in the list, but not later.  The `tests.data.callables`
submodule and the `tests.machinery` subpackage differ in that the
`test.data.callables` are still expected to be functional and useful
even without a testing system, the latter not necessarily.
</pre>

Change the code style to use double quotes for strings

2025-08-05T21:11:03+02:00

As is standard in Python auto-formatting (Black, Ruff), we now use
double quotes for strings where possible, reverting to single quotes
only where necessary.

(The numerous code changes in `scripts/`, `src/` and `tests/` stem from
the auto-formatter re-adjusting the quotes.)

Background: I originally started out as a Perl programmer, and in Perl,
single quotes signify literal strings without any interpolation
whatsoever, and double quotes signify strings with interpolation and
escape sequences. In those languages, the choice of string quotes makes
a subtle difference. In Python, the choice of quote character does not
matter, so while there is no reason to prefer one over the other, the
inertia of being used to "single means literal, double means
interpolated" meant that I basically kept my existing style of quoting.

Python, meanwhile, although careful not to *prescribe* one quote
character or the other (see PEP 8), uses double quotes by default in
`str.__repr__` and in docstrings (see PEP 257). The Black
auto-formatter, which Ruff is modeled on, also defaults to double
quotes, arguing in its style guide that (among other things) the empty
string with double quotes unambiguously looks like an empty string,
regardless of fonts and syntax highlighting, but the empty string with
single quotes not necessarily: it may look like a single double quote
character.

More importantly, auto-formatters are specifically designed to make
these (essentially arbitrary) decisions about code formatting for you,
in the name of a uniform code style such that a reader can focus on the
code *content*, not the code *presentation*.  The concrete set of
arbitrary decisions is essentially secondary, but the Black team (and
the Ruff team too) have a pretty good track record of keeping the
resulting code readable and sensibly diffable, and this styling decision
has long been established by Black and "blackened" code "in the wild"
(and thus tested), so I have no reason to object to this particular
arbitrary choice.  Furthermore, there's no need to manually adjust all
quote characters, or even to pay much attention during code authoring to
the quote characters; the auto-formatting pass will take care of
harmonizing them for you.

Given these reasons, continuing to insist on single-quoted strings, in
Python, out of some vague sense of familiarity with *other* programming
languages where quote characters have different meanings, seems rather
untenable to me.
</pre>

Merge topic branch 'ssh-agent-socket-providers' into master

2025-08-04T21:41:47+02:00

* ssh-agent-socket-providers:
  Add a changelog entry for the SSH agent socket provider feature
  Make all command/format/feature enums self-testing
  Document the new level of support for SSH agents (also in `--version` output)
  Update the "SSH key" feature flag in `--version` output
  Support looking up a socket provider, even if merely registered
  Add tests for the SSH agent socket provider machinery
  Introduce a stubbed SSH agent, for testing
  Introduce SSH agent socket providers
  Turn the `ssh_agent` submodule into a subpackage
  Generalize the error message for missing SSH agent support
</pre>

Add a changelog entry for the SSH agent socket provider feature

2025-08-04T21:37:03+02:00

Also include a changelog entry for the self-testing feature flags.
</pre>

Update wishlist to post-v0.5.2

2025-08-03T21:57:58+02:00

</pre>

Release 0.5.2

2025-08-03T21:47:37+02:00

</pre>

Merge topic branch 'fix-version-number' into master

2025-08-03T20:45:36+02:00

* fix-version-number:
  Fix the automatic version increment in `__init__.py`
</pre>