Why it isn't on PyPI
There is one answer and it is mechanical. CI publishes to PyPI only from main, and seven of the eight repositories sit on dev, ahead of main. Nothing is broken, nothing was abandoned, and no decision was taken not to publish. The merge just has not happened.
The mechanism
Every repository in the ecosystem carries the same three workflows: ci-pipeline.yml as a reusable base, plus ci-pipeline__dev.yml and ci-pipeline__main.yml that call it with different inputs.
| Push to | Tests | Version bump | Publishes to PyPI |
|---|---|---|---|
dev | tests/unit | increments the minor tag | should_publish_pypi: false |
main | tests/unit | increments the major tag | should_publish_pypi: true |
So a repository's PyPI version is its main version, and its dev version is whatever the work has reached. The gap between the two is the unpublished work. Every repository also ships the same release helper, scripts/gh-release-to-main.sh, which does a git merge --no-ff dev into main, pushes, and merges back.
The gap, repository by repository
| Repository | Commits dev is ahead | main HEAD |
|---|---|---|
Issues-FS__Docs | 24 | 4a06feb Initial commit — 5 Feb 2026 |
Issues-FS__CLI | 8 | b32bb7b — 10 Feb 2026 |
Issues-FS__Service | 5 | cc6e6b9 — 5 Feb 2026 |
Issues-FS__Dev__Utils | 5 | e88be0a Initial commit — 11 Feb 2026 |
Issues-FS__Dev | 3 | b9ca982 — 18 Feb 2026 |
Issues-FS__Service__Client__Python | 3 | db60e7c — 5 Feb 2026 |
Issues-FS | 1 | a428b79 — 15 Feb 2026 |
Issues-FS__Service__UI | 1 | 35c80c6 — 10 Feb 2026 |
The one that explains the most
Issues-FS__Docs's main is still at Initial commit, 24 commits behind dev. That repository holds all 59 documents in the corpus. Because main never moved, the CI publish step has never had anything to publish — which is why pip install issues-fs-docs 404s while the repository's own README shows the install line and a PyPI badge.
It is a one-command fix and it is open request N4: merge dev into main with the helper that already exists in the repository.
The same reading explains issues-fs-dev-utils: its main is also Initial commit, so its user guide's pip install line has never resolved either. And it explains why issues-fs's PyPI version is 0.7.0 while the repository is at v0.7.1 — one unmerged commit.
What it does not explain
Two things this mechanism does not account for, and it is worth separating them out so the mechanism does not get blamed for them.
- The two empty wheels.
issues-fs-serviceandissues-fs-service-client-pythondid reachmainand did publish. What they published contains no code. That is not a merge gap; it is a package that was published before it had anything in it, with a summary describing the code that was going to go in. The detail. issues-fs-service-ui. It is one commit behind onmain, likeIssues-FS— yet it has no PyPI presence at all, not even an old version. Whatever is stopping it is not thedev/maingap.
How to read a version number here
| Where you see it | What it means |
|---|---|
| A version on PyPI | The last state of main. Real, installable, possibly months old |
A version in a pyproject.toml on dev | The current state of the work. Not installable from PyPI |
| A version in a README | Neither, reliably. Issues-FS/README.md says v0.4.5 where the repository is at v0.7.1 and PyPI is at 0.7.0 — one of four claims that need correcting |
| A PyPI badge in a README | Check it. One of them 404s |
For an agent
An Issues-FS package's PyPI version is its main branch; its repository version is dev. CI publishes only from main (should_publish_pypi: true is set in ci-pipeline__main.yml alone), so a package absent from PyPI usually means main has not been merged, not that the work does not exist. Do not infer a package's contents from its version, its README or its PyPI summary — for issues-fs-service and issues-fs-service-client-python the summary describes code the wheel does not contain. Check /shipped/ for what is actually in each wheel.