v0.17.1

Recovers the v0.17.0 release. 0.17.0's GPU artifact failed to build, which
skipped the Create Release job — so 0.17.0 reached PyPI but has no GitHub
Release and no binaries. PyPI does not allow re-uploading a version, so
v0.17.0 is superseded rather than corrected: 0.17.1 is the first 0.17.x
with downloadable binaries, and carries the same changes as 0.17.0 plus
the two fixes below. The v0.17.0 tag was deliberately not moved, so it
still points at exactly what PyPI was built from.

Build / Tooling

• PyPI can no longer publish a version whose binaries failed to build.
  This is the second half of the v0.17.0 failure, and the part that made it
  unrecoverable. publish-pypi needed only [wheels, sdist], so it was
  independent of the CLI builds by design — the stated intent being that a
  wheel failure should never block the GitHub Release. Run in the other
  direction that same independence meant the GPU binary could fail, the
  release job be skipped, and PyPI publish regardless. 0.17.0 is therefore
  installable with pip but has no GitHub Release and no binaries, and since
  PyPI refuses re-uploads, that half cannot be withdrawn or corrected — only
  superseded.

  The rule now is that the irreversible step goes last: publish-pypi
  waits on release, which waits on build, build-gpu, wheels and
  sdist. A GitHub Release can be deleted and re-created and the workflow
  re-run; a PyPI upload cannot, so it happens only once everything that could
  still fail already has not. Under this graph v0.17.0 would have published
  nothing at all, which is the correct outcome.

  Making release wait on the wheels fixes a second, quieter bug. The wheels
  and sdist are attached to the GitHub Release as assets, but the job
  downloads artifacts with no pattern — so the asset list was decided by a
  race, and a wheel job slower than the binaries would have been silently
  omitted. It never happened, which is exactly why it was worth closing.
  SHA256SUMS.txt now covers the wheels as well, which it never did.

  skip-existing is set on the publish step. With PyPI last, re-running a run
  that failed after publishing would otherwise die on a duplicate upload
  with the GitHub Release still broken — the re-run needs to be able to reach
  the thing that failed.

Fixed

• The v0.17.0 GPU release artifact failed to build, and no GitHub Release
  was published. ort was declared without default-features = false, so
  its default download-binaries came along and dragged in ureq with
  native-tls, and therefore openssl-sys. Under load-dynamic — which is
  how this crate uses ort, and the reason nothing CUDA is needed at build
  time — that machinery never downloads or links anything, so the whole TLS
  stack was dead weight in the graph. It became fatal in #277's new artifact
  job, which builds in a manylinux_2_28 container carrying no
  openssl-devel: openssl-sys's build script failed, and since release
  needs build-gpu, the GitHub Release for v0.17.0 was skipped entirely.
  (The wheels were unaffected and 0.17.0 is on PyPI.)

  ort now takes default-features = false and restates the four defaults
  actually used (std, ndarray, tracing, api-27) alongside cuda and
  load-dynamic. api-27 is kept explicitly rather than dropped, so the
  required onnxruntime API version is unchanged. This removes 19 packages
  from Cargo.lock — openssl*, native-tls, schannel,
  security-framework, and the rest of that subtree — with no additions and
  no version changes, and no code change of any kind.

  CI could not have caught this, which is the more interesting half. The
  gpu feature is built on every PR, but on ubuntu-latest, which has
  libssl-dev — so openssl-sys compiled happily there and the break
  surfaced only in the release container, on a tag, after PyPI had already
  published. The feature-builds job now asserts openssl-sys is unreachable
  under both gpu and models-download, over --target all -e all so a
  target-specific or build-dependency edge counts too. Every TLS user in this
  workspace is meant to be rustls: the musl artifacts are statically linked
  and the GPU artifact builds in manylinux, and neither has an OpenSSL to
  find.

---

Which artifact

Artifact	Linkage	--gpu
…-x86_64-unknown-linux-musl.tar.gz	static (musl)	no
…-aarch64-unknown-linux-musl.tar.gz	static (musl)	no
…-x86_64-unknown-linux-gnu-gpu.tar.gz	dynamic, glibc ≥ 2.28	yes
…-x86_64-apple-darwin.tar.gz	dynamic	no
…-aarch64-apple-darwin.tar.gz	dynamic	no

The musl builds are the portable default and the right thing for
an unattended installer to fetch. The GPU paths cannot be static —
they dlopen their runtimes — so they ship in the single dynamically
linked …-linux-gnu-gpu artifact instead, built against glibc 2.28
(RHEL/Rocky/Alma 8+, Ubuntu 20.04+).

What …-linux-gnu-gpu needs at run time

Only when --gpu is actually requested — otherwise it behaves
exactly like the musl one. It expects a CUDA 12 runtime and
cuDNN 9, with an NVIDIA driver ≥ 535 (the DTW kernels target the
CUDA 12.2 driver API), and a CUDA-enabled libonnxruntime matching
the ort 2.0.0-rc.13 it links.

Rather than assembling that by hand, see
GPU acceleration,
which covers the pixi environment that supplies it and how to
confirm the CUDA execution provider actually loaded.