Recent commits to derivepassphrase.git (25d4b90f83405a030224b2f52cb0951c76e75ef6)

Repair the --version output test for derivepassphrase export vault

2026-08-23T17:23:09+02:00

The test was no longer triggering the fallback behavior for when the
"export" extra/the "cryptography" library was not available.  Partially,
this was because we now need to parametrize this test for both cases,
but forgot to do so.  Partially, this was *also* because querying the
installed version of "cryptography" needs to be separately mocked,
beyond just blocking the import.
</pre>

Officially support and test on Python 3.15

2026-08-23T14:58:43+02:00

Currently at release candidate 1.
</pre>

Fix hypothesis dependency on PyPy 3.9 and PyPy 3.10

2026-08-23T12:56:29+02:00

Because `hypothesis` requires a Rust toolchain for building 6.156 and
higher, and because this is not installable on PyPy 3.10 and lower, pin
`hypothesis` to 6.155.* and lower on PyPy 3.9 and 3.10.

This was already broken for quite some time, but cropped up again after
redoing the virtualenvs in commit
4fbfed4a4de887bd35f295863ea7548989024bf7.
</pre>

Always test the "no cryptography support" scenario, shrinking the test matrix

2026-08-23T12:44:07+02:00

Even when the `cryptography` library is available, we test the fallback
behavior of `derivepassphrase export vault` by inhibiting the loading of
`cryptography`.  As a result, we no longer need a separate testing
environment for the "no cryptography support" case, and can therefore
halve the number of configurations in our testing matrix.  We also no
longer need some associated configuration and helper objects.

In hindsight, I cannot believe I never tried to do a web search on how
to inhibit loading of a module in Python, and rather assumed that just
because pytest does not prominently offer a dedicated top-level function
or a dedicated `monkeypatch` method, that this is not supported.  But
seeing the underlying documentation for `importlib.import_module` and
the documentation of how `sys.modules[...] = None` affects the module
resolution, it becomes immediately obvious that this can be handled with
monkeypatching, and does not need a separate virtualenv.
</pre>

Set the Python path correctly during pytest invocation, round two

2026-08-23T12:24:05+02:00

In commit 0bf24eb16ec698d7759657cb810385ec7388f74c, we added the current
directory explicitly to pytest's `pythonpath` configuration to avoid
failing tests.  Further analysis revealed that the culprit was the
multiprocessing module with the `spawn` method, which needs to re-import
the module it is called from (and other helper code from the
`tests.data` and `tests.machinery` submodules), but is not compatible
with some ways of modifying Python's module search path before module
loading.

According to my search results, the common way of dealing with this
problem is instead to add the `tests` path to `pythonpath`, instead of
the parent directory.  Furthermore, it is unnecessary to explicitly add
the `src` directory to `pythonpath`, as the virtualenv in which the
tests run already has `derivepassphrase` installed.  So we can reduce
the `pythonpath` to only `tests`, and add an appropriate comment as to
why this entry specifically is needed.

We also add comments to the entries in `testpaths`, because it may not
be immediately obvious that the `src` entry is needed for the doctests.
</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>

Update the translation template, the German translation, and the message catalogs

2026-07-05T22:34:45+02:00

</pre>