Ask: Cut a release of oui from the current default branch, so the version on PyPI stops declaring argh. Either publish once by hand from a checkout, or say the word and CI can be set up to do it — see the options below.
Verify: curl -fsS https://pypi.org/pypi/oui/json | python3 -c 'import json,sys; d=json.load(sys.stdin)["info"].get("requires_dist") or []; sys.exit(1 if any(r.split()[0].split(";")[0].strip()=="argh" for r in d) else 0)'
Evidence: https://pypi.org/project/oui/0.3.3/ declares argh. The commit removing it is 98d8309.
Blocks: closing out oui in the argh/licence sweep. The repo is already done; only the published artifact is not. Nothing else in the fleet depends on oui.
Why this one needs a person
The code fix is finished and merged. argh (LGPL-3.0-or-later) was the only entry in install_requires and was imported nowhere — git grep -i argh over the tracked tree now returns zero hits, and the whole install_requires key is gone, so oui has no third-party runtime dependencies at all.
But the released artifact is what people install, and it is unchanged. oui 0.3.3 was uploaded on 2022-12-31 and still declares argh, so every pip install oui today still pulls an LGPL package that oui never uses. That exposure stays live until there is a new release.
This repo has no CI at all — no .github directory — so there is no automated path from the merged fix to a release. That is the entire gap.
The credential is not the problem here, which makes this cheaper than it looks
Unlike the other repos in this sweep, oui already has working PyPI credentials: it is under i2mint, and the organisation has an all-repos PYPI_PASSWORD secret that is known good — cw 0.0.15 published with it on 2026-05-27. No new secret needs setting.
The options
A — publish once, by hand. Bump the version in setup.cfg (0.3.3 to 0.3.4), python setup.py sdist, and upload. This uses the same build path that produced 0.3.3, so the packaged contents are unchanged apart from the metadata, and it closes the exposure today. Smallest possible change.
B — set up CI that publishes. The right long-term answer, but it is more than dropping in the usual stub: oui is still setup.cfg plus setup.py, and the wads reusable workflow expects pyproject.toml. Converting means re-deriving the packaging rules for the non-Python files the package ships — a committed 850 KB JavaScript bundle under the package, plus several dozen config fixture files — currently handled by MANIFEST.in and include_package_data. There is essentially no test suite to catch a packaging regression.
C — do nothing. The exposure stays live indefinitely. Listed only for completeness.
Recommendation: A now, B later and separately. A is minutes and removes the live exposure. B is worth doing but it is a packaging migration, and bundling it into this makes the licence fix wait on it.
Why I set up neither A nor B rather than just doing it
I have admin on this repo and the organisation credentials would have worked, so this was a judgement call rather than a permissions wall. Two reasons not to:
The packaging migration (B) is not safe to do blind. Getting the package-data rules wrong under a new build backend ships an oui missing its JavaScript bundle or its fixtures. That is a functional break, which is strictly worse than the metadata problem being fixed — and with one test file in the repo, CI would not catch it.
Auto-publishing (A via CI) from a repo that has never had a CI run is the shape of mistake this sweep already had one near-miss on. Turning on a publish job in a repo where nobody has ever watched one run, unattended, is how a package ends up somewhere nobody intended. It seemed clearly right to hand you a decision rather than take it.
If you would rather I just did A, say so on this issue and it is a short job.
What is actually in the current tree
setup.cfg has no install_requires key at all.git grep -i argh over tracked files: zero hits.import oui succeeds; the one test file passes.- Version in
setup.cfg is still 0.3.3, matching what is on PyPI, so a bump is needed before any upload — PyPI will not accept a re-upload of an existing version.
Ask: Cut a release of
ouifrom the current default branch, so the version on PyPI stops declaringargh. Either publish once by hand from a checkout, or say the word and CI can be set up to do it — see the options below.Verify:
curl -fsS https://pypi.org/pypi/oui/json | python3 -c 'import json,sys; d=json.load(sys.stdin)["info"].get("requires_dist") or []; sys.exit(1 if any(r.split()[0].split(";")[0].strip()=="argh" for r in d) else 0)'Evidence: https://pypi.org/project/oui/0.3.3/ declares
argh. The commit removing it is 98d8309.Blocks: closing out
ouiin the argh/licence sweep. The repo is already done; only the published artifact is not. Nothing else in the fleet depends onoui.Why this one needs a person
The code fix is finished and merged.
argh(LGPL-3.0-or-later) was the only entry ininstall_requiresand was imported nowhere —git grep -i arghover the tracked tree now returns zero hits, and the wholeinstall_requireskey is gone, soouihas no third-party runtime dependencies at all.But the released artifact is what people install, and it is unchanged.
oui0.3.3 was uploaded on 2022-12-31 and still declaresargh, so everypip install ouitoday still pulls an LGPL package thatouinever uses. That exposure stays live until there is a new release.This repo has no CI at all — no
.githubdirectory — so there is no automated path from the merged fix to a release. That is the entire gap.The credential is not the problem here, which makes this cheaper than it looks
Unlike the other repos in this sweep,
ouialready has working PyPI credentials: it is underi2mint, and the organisation has an all-reposPYPI_PASSWORDsecret that is known good —cw0.0.15 published with it on 2026-05-27. No new secret needs setting.The options
A — publish once, by hand. Bump the version in
setup.cfg(0.3.3 to 0.3.4),python setup.py sdist, and upload. This uses the same build path that produced 0.3.3, so the packaged contents are unchanged apart from the metadata, and it closes the exposure today. Smallest possible change.B — set up CI that publishes. The right long-term answer, but it is more than dropping in the usual stub:
ouiis stillsetup.cfgplussetup.py, and the wads reusable workflow expectspyproject.toml. Converting means re-deriving the packaging rules for the non-Python files the package ships — a committed 850 KB JavaScript bundle under the package, plus several dozen config fixture files — currently handled byMANIFEST.inandinclude_package_data. There is essentially no test suite to catch a packaging regression.C — do nothing. The exposure stays live indefinitely. Listed only for completeness.
Recommendation: A now, B later and separately. A is minutes and removes the live exposure. B is worth doing but it is a packaging migration, and bundling it into this makes the licence fix wait on it.
Why I set up neither A nor B rather than just doing it
I have admin on this repo and the organisation credentials would have worked, so this was a judgement call rather than a permissions wall. Two reasons not to:
The packaging migration (B) is not safe to do blind. Getting the package-data rules wrong under a new build backend ships an
ouimissing its JavaScript bundle or its fixtures. That is a functional break, which is strictly worse than the metadata problem being fixed — and with one test file in the repo, CI would not catch it.Auto-publishing (A via CI) from a repo that has never had a CI run is the shape of mistake this sweep already had one near-miss on. Turning on a publish job in a repo where nobody has ever watched one run, unattended, is how a package ends up somewhere nobody intended. It seemed clearly right to hand you a decision rather than take it.
If you would rather I just did A, say so on this issue and it is a short job.
What is actually in the current tree
setup.cfghas noinstall_requireskey at all.git grep -i arghover tracked files: zero hits.import ouisucceeds; the one test file passes.setup.cfgis still 0.3.3, matching what is on PyPI, so a bump is needed before any upload — PyPI will not accept a re-upload of an existing version.