0.4.0

qsv 25.0.0 is the first qsv release whose binaries (qsv, qsvlite, qsvdp, qsvmcp) all answer --capabilities and report errors as JSON. qsv-client 0.4.0 makes it the minimum and drops the code that supported older qsv.

⚠️ Behavior change: qsv 25.0.0 or later is required

Before its first command, every client now runs qsv --capabilities. Previously this check only happened when you passed min_version=. A qsv that is too old raises QsvVersionError instead of running:

qsv = Qsv("/usr/local/bin/qsv")   # qsv 24.0.0
qsv.count("data.csv")
# QsvVersionError: /usr/local/bin/qsv does not support --capabilities;
#                  qsv 25.0.0 or later is required

• MIN_QSV_VERSION ("25.0.0") is exported. min_version= can still raise the floor, but not lower it.
• The check uses the run's timeout (at most 60s), separately from the command. So a client's first run can take up to about twice its timeout. Later runs aren't affected.
• If the check fails for another reason, such as a crash or a startup error, you get the usual QsvError with qsv's stderr, not a version error.

Upgrade qsv before upgrading qsv-client. (#9)

⚠️ Behavior change: QsvVersionError is now a QsvError

Because any run() can now raise it, QsvVersionError subclasses QsvError, with kind version. So except QsvError around run() catches a too-old binary too.

try:
    qsv.run("stats", "data.csv")
except QsvVersionError:   # must come first: a later `except QsvVersionError` is never reached
    ...
except QsvError:
    ...

Generic QsvError handlers now see version errors as well. Retry logic shouldn't retry them, because a too-old qsv will never succeed. The error's exit_code, args_run and stderr describe the --capabilities check. (#10)

Capabilities are checked once per process

--capabilities now runs at most once per qsv binary per Python process, and every Qsv and AsyncQsv shares the result. So creating a client per call (for example, one per web request) doesn't start an extra qsv each time.

• Concurrent first calls from threads, or from coroutines on the same event loop, share one check.
• A binary replaced in place (new size or modification time) is checked again.
• Each client still applies its own min_version and gets its own copy of the result.
• Values in raw that depend on the environment, such as max_jobs, come from the client that checked first.

(#9, #10)

Removed

• The --version / --list fallback, including qsv_client.capabilities.from_version_output. If --capabilities succeeds but its output can't be used, capabilities raises QsvError. (#9)
• Capabilities.supports_json_errors and Capabilities.error_formats. Every supported qsv reports JSON errors. The value is still in raw["error_formats"]. (#10)
• Capabilities.raw is no longer optional. It's always the parsed --capabilities output, and Capabilities fields are now keyword-only. (#10)

Under the hood

• Errors are still classified by exit code when qsv dies without writing a JSON error line, for example after a panic or a signal.
• CI no longer runs the integration tests against a pinned qsv 24.0.0. Unit tests simulate a qsv that rejects --capabilities, and the integration tests check that every binary variant reports JSON errors.

Full changelog: 0.3.0...0.4.0