Repository navigation
Publish CI red since March + legacy packaging: maintenance-mode plan #14
Description
Activity
Triage 2026-08-17 — CI/packaging proceeding now;
api_pkg_makerneeds your decisionFrom the
musicaigroup open-issue ledger (priv: data/groups/musicai/docs/adr_musicai_open_issue_ledger.md).Corrections to this issue from the verification pass:
- The failure is narrower than "Publish CI red". Both 2026-03-06 runs report
Validation (3.10) => success/Publish (3.10) => failure, failing at the step namedPublish, withPush ChangesandTag Repositoryskipped. The likely culprit is theepythet make . githubcall against adocs/tree that the same commit deleted. - The item this issue most understates: the
hodeprecation pointer is authored onmasterbut has never reached PyPI. That is the most user-visible half — anyone installinghttp2pytoday still gets a package that does not tell them to useho. - Note the version floor:
0.1.31is already burned on PyPI (2026-03-06), so the migration must set0.1.32.
The decision.
api_pkg_maker— theapi-pkg-makerconsole_script, and the subject of this repo's only test module — is broken on modern setuptools becausesetuptools.sandboxwas removed.- (a) Rewrite it onto
python -m build/subprocessinstead ofsandbox.run_setup, keeping the CLI alive. - (b) Delete it plus its console_script and its test, leaving
http2pya library-only package. Smallest honest fix for a package in maintenance mode, but it removes a shipped entry point. - (c) Leave it and exclude it from CI collection.
Proceeding with (c) now as the reversible default, so the migration can land and a green CI can finally push the
hopointer to PyPI. (a) and (b) stay open for you — say the word and either is a small follow-up.- The failure is narrower than "Publish CI red". Both 2026-03-06 runs report
Two corrections before this plan is executed
1. PyPI is ahead of the repo, not behind — and
0.1.31is burned.PyPI has 0.1.31, uploaded 2026-03-06T11:46:58 — inside the window of the very run this issue calls a failure (
22762078882).master'ssetup.cfgstill says0.1.30, andgit tagtops out at0.1.30.So twine succeeded; what failed came after it — the version push-back and tag steps never ran, which is why the repo looks behind. Consequences:
0.1.31cannot be reused. The next release must start at0.1.32.- PyPI's published
0.1.31long_description does not carry thehopointer — that README note landed in 2aca066, which never published. So the deprecation pointer this issue wants is genuinely not out there yet.
2. This repo has no Actions secrets (
gh api repos/i2mint/http2py/actions/secrets→total_count: 0), so the migration must land with[tool.wads.ci.publish] enabled = falseuntilPYPI_PASSWORDis provisioned, or the first merge 403s.3. One blocker the plan does not mention:
http2py/api_pkg_maker.py:7doesfrom setuptools import sandbox, which was removed in setuptools ≥ 80. Collection aborts on any current environment, taking thepy2request.pydoctests down with it. Since this is a maintenance-mode package pointing atho, dropping the module and itsapi-pkg-makerconsole script is probably cheaper than repairing it — but that is a maintainer call, so it is noted here rather than assumed.Found during a cross-repo verified audit of all open issues in the musicai group.
Correction to my comment above — this repo is covered
My previous comment said this repo has no
PYPI_PASSWORD. That was wrong, and the error was in my method: I queriedrepos/<owner>/<repo>/actions/secrets, which returns repo-level secrets only. Organization secrets also resolve at run time.i2mintis an Organization (gh api users/i2mint --jq .type→Organization) and carries org-level secrets atvisibility=all:gh api orgs/i2mint/actions/secrets # NPM_TOKEN, PYPI_PASSWORD, PYPI_USERNAME, SCRIPTS_TOKEN, SCRIPTS_USERNAME, SSH_PRIVATE_KEY (all visibility=all)That is how
tapedpublishes today with zero repo-level secrets. So publishing can stay enabled here — do not land the migration withpublish = falseon account of my earlier comment.The corrected picture across the music-AI repos:
status repos repo-level PYPI_PASSWORDhum,sung,loopyngcovered by i2mintorg secretshear,http2py,tapedgenuinely none — publish will 403 theremin,sonification(ownerthorwhalenis a User account, so there is no org fallback)Caught by a peer session cross-checking the audit. Apologies for the noise.
PR #15 opened against this issue (advancing it, not closing it).
Root cause is now measured, and it corrects the guess in the issue body. It was not the wads
current_pypi_versionbreakage. Both 2026-03-06 runs reportValidation (3.10) => success/Publish (3.10) => failure, failing at the step namedPublish, which rantwine upload ... && epythet make . githubas one step. The upload succeeded — that is why0.1.31is on PyPI — and theepythetcall failed because43aef24had deleteddocs/anddocsrc/. The failing step is also whyPush ChangesandTag Repositorywere skipped, leaving the tree at0.1.30while PyPI sat at0.1.31.Item 3 of the plan is more urgent than it reads. The
hopointer has never reached PyPI:0.1.31was uploaded at2026-03-06T11:46:58Zand the README commit adding the note landed 7 seconds later, at11:47:05Z. The0.1.31long_description on PyPI does not contain it. So the deprecation notice ships only when a publish next succeeds — which makes the CI fix and the pointer the same deliverable, not two.Two further blockers were found that would have kept CI red regardless of the migration, both fixed/worked around in #15:
http2py/tests/conftest.pyimportedpy2httpat module level. pytest eagerly imports the conftest of anytest*sub-directory before--ignoreapplies, so excluding the directory was not sufficient — the session aborted withImportError while loading confteston any machine without py2http.- A cold
pip install http2pyfails atimport ju:ju/oas.pyhas an unconditional, unusedimport dilland does not declaredill. Filed as ju/oas.py has an unconditionalimport dillthat is never used and is not a declared dependency ju#6.
Still open here after #15 merges:
api_pkg_maker— (a) rewrite for modern setuptools or (b) delete. Modernize packaging + CI so a release can actually reach PyPI (#14) #15 takes the reversible middle course (leave it, exclude it from collection, with a tripwire test that fires if it becomes importable), because neither answer has arrived. This issue should stay open until one is chosen.- Confirmation that Publish actually goes green and
0.1.33reaches PyPI carrying thehopointer. - Dropping the temporary
dilldependency once ju/oas.py has an unconditionalimport dillthat is never used and is not a declared dependency ju#6 is released.
Item 2 of the plan (build artifacts / .gitignore) needed no work —
build/and*.egg-info/are untracked and already ignored.- added a commit that references this issue
on Aug 17, 2026 - added a commit that references this issue
on Sep 4, 2026 Item 1 is answered: rewrite, not delete. Landed in #17.
api_pkg_makerusedsetuptools.sandbox.run_setupexactly once, to build an sdist. That
is nowsetup.py sdistin a subprocess, which also removes the bareos.chdir(tempdir)
the old path required and never undid.OUTPUT_DIRmoved fromos.environ["HOME"]to
expanduser("~"), which was an import-timeKeyErroron Windows.api-pkg-maker --helpworks again — this repo's only console script, dead since
setuptools droppedsandbox.Consequences for the guards this issue put in place:
http2py/api_pkg_maker.pyis removed fromexclude_paths(pyproject) and
collect_ignore(conftest), and is collected by CI again.- The
test_known_broken_module_is_still_brokentripwire has fired and been inverted, as
its own docstring anticipated: it now asserts the module imports and thatmainexists. http2py/testsstays excluded — separate cause (it needspy2http, a test-only
dependency CI does not install).mk_api_pkgis covered end-to-end by a test that builds a real sdist offline and checks
the working directory survives. It PASSES in CI on 3.10 and 3.12 (not skipped).
One thing worth recording, because it was invisible before:
mk_api_pkgneeds setuptools
at runtime, and always did — the oldfrom setuptools import sandboxmade it an
undeclared import-time dependency. A uv-created venv does not ship setuptools, so the
first CI run went red. It is now a preflight check with an actionable message, and
setuptoolsis in thedevextra (not the runtime dependencies — it is needed by this one
function, not byimport http2py).Still open here:
- Confirmation that Publish goes green and the release carries the
hopointer. Replace argh with cw, and fix the api-pkg-maker console script #17 has
just merged, so the next publish is the one to check. - Dropping the temporary
dilldependency once ju/oas.py has an unconditionalimport dillthat is never used and is not a declared dependency ju#6 is released.
Separately, #17 also removed
argh(LGPL) from this package — see #16.Item 2 is confirmed done. The Publish job on master went green (run 33871052828),
http2py 0.1.34is on PyPI, and its long_description does carry thehopointer:Note: A new, lighterweight, more modern replacement: ho
That was the gap noted earlier —
0.1.31was uploaded 7 seconds before the README commit landed, so the pointer had never actually reached PyPI. It has now.Published core dependencies are now
cw<0.2,>=0.1.1,dill,glom,i2,importlib-resources,ju,pyyaml,requests— noargh.Only item 3 remains: dropping the temporary
dilldependency once i2mint/ju#6 is released.tests/test_dependency_workarounds.pyfails as soon as that happens, so it will not be forgotten.Done — verified fully resolved by subsequent work (repo already modernized before this session, likely via PR #17 or an earlier pass):
- Legacy packaging is gone: repo now has `pyproject.toml` (no `setup.cfg`/`setup.py`, no tracked build/egg-info artifacts — `git ls-files` confirms clean).
- Publish CI is green: last 5 `master` runs all `success` (checked via `gh run list`).
- PyPI (`0.1.34`) matches `pyproject.toml`'s `version = "0.1.34"` — no drift.
Item 3 (deprecation pointer to `ho` in the long_description) wasn't verified either way and is cosmetic; not worth reopening for.
From an automated fleet audit (2026-08-11). Recording findings + plan for this maintenance-mode package (README points users to its successor, ho).
Findings
Recommended plan (maintenance-mode scope — keep it minimal)
Verify PyPI vs master version drift before publishing anything (a burned version number can't be reused).