The PyPI name this repo would publish under belongs to yunojuno/django-perimeter

[ChelseaKR]

What is wrong

pyproject.toml declares name = "perimeter". That name is already taken on PyPI by a different project:

$ curl -s https://pypi.org/pypi/perimeter/json | jq '.info.version, .info.home_page, .info.author'
"0.14"
"https://github.com/yunojuno/django-perimeter"
"YunoJuno"

So the first attempt to publish under perimeter will be rejected, and — worse — any automated check that asks "is this project on PyPI?" by name will answer yes, at 0.14, which is somebody else's Django middleware.

This is not hypothetical: a portfolio-wide release check hit exactly that trap on its first pass and reported INDEX_AHEAD_OF_REPO: pypi has 0.14 but the repo declares 0.1.0 for this repository — a completely plausible finding about an entirely unrelated package. It only stopped being wrong once the checker started verifying that the PyPI entry's own repository URL and author actually match this repo.

Why it matters here

#49 ("Cut the first signed tag") is open. The name collision is upstream of it: a signed tag that names an artifact nobody can install under that name is a tag with no destination.

The repo is otherwise in a clean never-shipped state — no tags, no releases, nothing on PyPI — which is a fine place to be, but it means the name has never been tested against the index.

Also true: pyproject.toml says 0.1.0, CITATION.cff says 0.1.0, and package.json says 0.0.0.

What would help

Pick a distinguishing distribution name before the first publish, the way this portfolio already did for cairn-assistant, gauntlet-evals, nearmiss-safety, chalkline-ctdl, plumbline-eval and encore-plex — all of which have the same collision risk on their bare names and all of which avoided it. The import package name does not have to change with it.

Choosing the name is a product call, so nothing has been renamed, tagged or published here.

Found by a release-reality checker run across the portfolio on 2026-09-06 (condition INDEX_NAME_TAKEN).

Prepared with AI assistance; reviewed before submission.

[ChelseaKR]

Triage against origin/main @ dbef2c2 (2026-09-07). The finding holds and the reasoning about why it matters is right. Three things to add, one of which is a correction.

Confirmed. pyproject.toml declares name = "perimeter"; nothing here has been tagged or published; git ls-remote --tags origin is empty and the repository has no releases.

The "is it on PyPI?" trap is the important half of this issue, not the rejected upload. A first upload that fails is loud. A checker that asks the index by name and gets somebody else's package back is quiet, and it answers plausibly: 0.14, a real version, a real project, a real author. That is this portfolio's dominant defect wearing an unusually convincing disguise — not a missing read published as a value, but the wrong read published as the right one. Any check that resolves a project by bare distribution name has this failure mode, and the fix the checker adopted (verify the index entry's own repository URL and author against this repo) is the general answer, not a workaround for this one name.

A correction to the last paragraph of "Why it matters here." The three version numbers are not three declarations of one thing that disagree:

• pyproject.toml 0.1.0 and CITATION.cff 0.1.0 describe this distribution, and they agree.
• package.json 0.0.0 describes perimeter-page-checks, which is "private": true and is the headless HTML/WCAG harness for the built pages. Its own description says nothing in it ships in the site. tools/a11y_browser/package.json is the same shape (perimeter-a11y-browser, 0.0.0, private).

A private, never-published dev-tooling package pinned at 0.0.0 is the conventional way to say "this is not versioned", not drift from 0.1.0. Worth striking from this issue so a future reader does not go and "fix" it into agreement, which would make package.json claim a version for something that has no releases and is not meant to have any.

Ordering. This is upstream of #49 as the issue says. It is also upstream of the py.typed work that landed in 89f1e73: that made the annotations a published interface for the project that pins this one, and the distribution name is what it would pin by, if it ever pins by name rather than by commit.

Not automatable. Choosing a distribution name is a product call and a permanent, public one — a name on PyPI cannot be taken back. Nothing renamed, nothing tagged, nothing published.

Needs from the owner: the name.

Triaged with AI assistance.

[ChelseaKR]

The collision this issue reports is gone. #81 (devrel/distribution-name) landed on main at 3a6aa47, and pyproject.toml now declares:

name = "perimeter-wildfire"

The import name and package directory are unchanged (import perimeter, src/perimeter/, python -m perimeter.acquire), and uv.lock was regenerated so the manifest and the lock agree — make lock-check is the gate that holds them together.

Re-checked today against the index: pypi.org/pypi/perimeter/json still answers 0.14 for YunoJuno's Django middleware, and perimeter-wildfire is unregistered. So the declared identity is one that could actually accept an upload, and a portfolio-wide release checker asking "is this project on PyPI?" by name no longer gets somebody else's package back.

Two things this deliberately did not do, both still true: nothing has been uploaded to any index, and this repository still has no publish workflow. The version strings named in this issue were reconciled separately by #68 (release/version-tag-honesty).

One loose end that is not this issue's: the comment above the name = line still describes perimeter-wildfire as "a placeholder pending confirmation, not a claim already made". Whether that wording can be dropped is the owner's call, and it is recorded in the campaign's owner-decisions file rather than changed here on a relayed approval.

Closing: the name collision is resolved.

Prepared with AI assistance; reviewed before submission.