Skip to content

Give the project a distribution name it could actually be released under - #81

Merged
ChelseaKR merged 2 commits into
mainfrom
devrel/distribution-name
Sep 7, 2026
Merged

ChelseaKR merged 2 commits into
mainfrom
devrel/distribution-name

Conversation

@ChelseaKR

Copy link
Copy Markdown
Owner

Draft on purpose: a distribution name is a public identity, and this one is yours to approve. Nothing here publishes, tags, or registers anything, and this repository still has no release workflow.

What was wrong

pyproject.toml declared name = "perimeter". That name on PyPI is YunoJuno's Django access-control middleware"Site-wide perimeter access control for Django projects", version 0.14 — verified again today (HTTP 200, author YunoJuno).

Nothing here has ever been published and there is no publish workflow, so nothing broke. But the declared identity was one that could never have accepted an upload, and a reader who did the obvious thing with a repository called perimeter got a Django middleware instead of a wildfire coverage measurement. The README described the served pages and the offline build and never said, in words, that there was nothing to install.

What changed

Three things, and none of them touch the measurement code.

  1. The distribution name is now perimeter-wildfire. Free on PyPI when chosen (checked 2026-09-07, HTTP 404). The import name and the package directory are unchanged: import perimeter, src/perimeter/, python -m perimeter.acquire. There is no console script, so nothing user-visible moves at all.

    Why this name. Five repositories here already hit this collision and solved it the same way — keep the word, add a qualifier: cairn-assistant, gauntlet-evals, nearmiss-safety, ledger-archive, plumbline-eval. perimeter-wildfire qualifies by domain, the way nearmiss-safety does, and that is the reading this repository needs specifically: the base word is the half that collides with an access-control package, so a qualifier that also reads as security (perimeter-checks, perimeter-coverage) leaves a reader on a PyPI page still unsure which project they are looking at. perimeter-wildfire cannot be mistaken for the middleware. perimeter-coverage was also free today if you prefer it; it is one string in pyproject.toml plus uv lock, and the comment there says so in place.

  2. uv.lock regenerated (uv lock), which is the only other place the string appears.

  3. The README says what a cold reader needs and could not previously get. A new paragraph under Status: there is nothing to install, nothing has been published to a package registry, there is no release workflow to publish it with, and pip install perimeter is somebody else's package. The Release & Versioning conformance row records the name decision beside the gap it belongs to.

Verification

  • make lint, make format, make typecheck --strict, make audit: green. uv run pytest: 922 passed, 25 skipped (the skips are the Node/Playwright a11y gates, which need make node-sync / make browser-sync; CI runs those).
  • Negative control on the lock/manifest coupling, which is what a rename can silently break. Baseline git hash-object uv.lock = b052b32d…; edited the lock's [[package]] name back to perimeter so it no longer matched the manifest; re-hashed and asserted the hash moved to 8536e5ed…; make lock-check went red — error: The lockfile at uv.lock needs to be updated, but --check was provided, exit 2. Restored, re-hashed to b052b32d… exactly, make lock-check exit 0.
  • A gate caught a real mistake on its first run and it is worth recording rather than hiding: tests/test_provenance.py::test_the_prose_carries_no_em_dashes[README.md] failed, because my new paragraph used an em dash. Fixed in its own commit.
  • One behaviour change worth knowing about, in make audit: pip-audit now reports perimeter-wildfire … Dependency not found on PyPI and could not be audited, where before it skipped the local project silently. Exit code is unchanged (0) and the skip is honest — the project genuinely is not on any index. It is a more accurate message, not a new failure.

What is still yours alone

Nothing in this branch needs anything from you except the name itself. For completeness, if this ever is packaged, the values PyPI's Add a pending publisher form would need are:

PyPI Project Name:  perimeter-wildfire
Owner:              ChelseaKR
Repository name:    perimeter
Workflow name:      (none yet — this repository has no release workflow)
Environment name:   pypi

The missing workflow is the existing recorded gap in the Release & Versioning row, and this branch does not close it. A name that is free today is not reserved; registration is what reserves it.

Deliberately not touched

#76 reads package.json's 0.0.0 as version drift. That is perimeter-page-checks, "private": true, never published to npm and never intended to be; it is not this collision and nothing here changes it.

Prepared with AI assistance; reviewed before submission.

pyproject.toml declared name = "perimeter", which on PyPI is YunoJuno's
Django access-control middleware. Nothing here has been published and there
is no release workflow, so nothing broke, but the declared identity was one
no upload could have used and a reader who typed it got a Django package.

The distribution is now perimeter-wildfire. The import name and the package
directory are unchanged. The README now says there is nothing to install
rather than leaving the collision to be discovered at a shell.
@ChelseaKR

Copy link
Copy Markdown
Owner Author

Name approved: perimeter-wildfire.

The domain qualifier over perimeter-coverage for the reason given in the PR: the base word collides with YunoJuno's access-control middleware, so any perimeter-<security-sounding-word> still reads as security and leaves a reader on the PyPI page unsure which project they are looking at. wildfire removes that ambiguity in one word.

Import name unchanged; only the distribution name moves. Nothing is published and there is no release workflow — the README now says so plainly rather than implying a future pip install that does not resolve.

Marking ready.

Prepared with AI assistance; reviewed before submission.

@ChelseaKR
ChelseaKR marked this pull request as ready for review September 7, 2026 18:01
@ChelseaKR
ChelseaKR merged commit 3a6aa47 into main Sep 7, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant