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.1textual[syntax]==6.1.0textual-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:
- 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.
- Compatible-release operators.
textual~=6.1 allows any 6.x but not 7. Stricter than option 1, looser than ==.
- 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.
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, onepython3-httpx, etc. in the repository, shared by every Python package on the system. A Fedorapython3-textualat, say, 7.0.0 has to satisfy all its consumers simultaneously. Ifpostingrequires exactlytextual==6.1.0it 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.1textual[syntax]==6.1.0textual-autocomplete==4.0.6Reproducibility doesn't have to suffer
I understand the original motivation: every user who installs
posting X.Y.Zshould get the same code. That's still achievable with a different split of responsibilities:pyproject.toml, exact pins inuv.lock.uv.lockalready provides reproducibility for normal installs;pyproject.tomlcan carry compatible ranges (e.g.textual>=6.1,<7). Distro packagers ignore the lockfile and use the ranges;pipx/uvusers get the same reproducible install they do today, because they install via the lockfile-aware tooling.textual~=6.1allows any 6.x but not 7. Stricter than option 1, looser than==.Option 1 is the standard approach across the Python packaging ecosystem (e.g. pip, black, mypy all do this).
Where things actually stand
The
.specfile and resulting RPM build cleanly otherwise —postinginstalls aspython3-postingwith auto-generatedRequires: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.