Should a project publish an sdist alongside its wheels, or are wheels enough?

### The question behind the question "Wheels only?" is really "who consumes my project, and by what path?" Wheels serve the majority path: an installer on a supported target that wants a fast, reproducible install. The sdist serves every other path, and the interview answer is about knowing what those paths are rather than reciting a rule. ### What a wheel-only release breaks **Targets outside your matrix.** A compiled project's wheels are valid only for the interpreter, ABI and platform combinations you built. Everyone else — a newly released Python minor, an architecture you do not have runners for, a platform variant with a different C library — previously had a slow-but-working source path. Take the sdist away and that becomes a flat failure to install, with a message that says nothing about the cause. **Source-based redistribution.** Operating-system distributions, scientific rebuild channels and internal mirrors that rebuild everything from source do not install your binaries; their policy is to compile from source with their own toolchain and patches. A wheel-only project cannot be packaged by them without them fetching the source from elsewhere, which turns your version-control host into an accidental part of their supply chain. **Audit and patching.** A wheel is a build output. It typically contains no tests, no build configuration, and — where the project is compiled — no source at all for the compiled part. A reviewer who wants to know what the released version actually contains, or an operator who needs a same-day fix in a dependency, needs the source that corresponds to the release, published under the same immutable version. ### What shipping an sdist costs It is not free, and pretending otherwise is the naive answer. **It must build.** The moment an sdist exists, installers may use it, and they will do so at the worst possible time — on a user's machine, in someone's deployment window. A tarball missing a header, a template, a generated version file or a build script fails there rather than in your CI. This is why a release build should build the wheel from the unpacked sdist, and why a release pipeline should have one job that installs the sdist on a clean image with only a toolchain present. **It leaks nothing you should have had.** An sdist ships your source layout and everything the backend was told to include. That is only a problem if you were relying on the wheel to omit something, which is not a security control in the first place. **It invites source builds you did not plan for.** Users on unbuilt targets will compile, and their result depends on their toolchain. You cannot prevent that by omitting the sdist — you only convert it into a failure — but you should be aware that it is a supported path and say in your documentation which targets are actually tested. ### The pure-Python case If a project has no compiled code it ships a single `py3-none-any` wheel that installs on every interpreter and platform, so the coverage argument largely evaporates: nobody is forced onto the source path by a tag miss. The remaining arguments still stand, and they are cheap to honour — the sdist costs one extra artefact in a build that already produces it by default, and it is what makes the release readable and rebuildable by people who are not you. ### The genuinely wheel-only case There is one: a private, internal distribution built by your pipeline for exactly the interpreters and images your organisation runs, consumed only from your own index. Every consumer is inside the matrix, source is available from version control to everyone entitled to it, and the deployment policy may even forbid source builds outright so that nothing is ever compiled at deploy time. Stating that case correctly — and noting that it stops being true the day an external team consumes the package — is what separates a considered answer from a memorised one. ### What to say in an interview Publish both by default; treat the sdist as a tested artefact rather than a by-product; verify it in CI by building the wheel from it and installing it on a clean image; and reserve wheel-only for a closed, internal audience whose targets you fully control. Then add the sharpest consequence: because published versions are immutable, an sdist you discover to be broken cannot be fixed in place — it costs a new version and a yank, which is a much worse afternoon than the CI job that would have caught it.