#353·posting

Relax pinned dependencies in pyproject.toml to enable Fedora/distro packaging

Author: gkneighbCreated May 7, 2026Updated May 7, 2026

Re-raising the topic from the now-locked #30 with concrete answers and a proposal, since I just hit this while packaging Posting 2.10.0 for Fedora.

In #30 you asked "is there some shared environment which is causing these conflicts?" — yes, exactly that.

Why distros can't take posting as-is

Fedora (and most Linux distros) follow a single-version policy: there is one python3-textual, one python3-httpx, etc. in the repository, shared by every Python package on the system. A Fedora python3-textual at, say, 7.0.0 has to satisfy all its consumers simultaneously. If posting requires exactly textual==6.1.0 it can't co-exist with anything else that needs newer textual on the same system.

The pins that currently block packaging:

  • httpx[brotli]==0.28.1
  • textual[syntax]==6.1.0
  • textual-autocomplete==4.0.6

Reproducibility doesn't have to suffer

I understand the original motivation: every user who installs posting X.Y.Z should get the same code. That's still achievable with a different split of responsibilities:

  1. Loose ranges in pyproject.toml, exact pins in uv.lock. uv.lock already provides reproducibility for normal installs; pyproject.toml can carry compatible ranges (e.g. textual>=6.1,<7). Distro packagers ignore the lockfile and use the ranges; pipx/uv users get the same reproducible install they do today, because they install via the lockfile-aware tooling.
  2. Compatible-release operators. textual~=6.1 allows any 6.x but not 7. Stricter than option 1, looser than ==.
  3. Status quo + Fedora patches. Distro maintainers patch out the pins downstream. This works but means every breaking change in textual potentially silently breaks distro builds with no upstream signal — worst of both worlds.

Option 1 is the standard approach across the Python packaging ecosystem (e.g. pip, black, mypy all do this).

Where things actually stand

The .spec file and resulting RPM build cleanly otherwise — posting installs as python3-posting with auto-generated Requires: for every dep, a man page, and a passing %check. The only remaining blocker for a Fedora review submission is the pins.

I'd be glad to send a PR for option 1 if you're open to it.