issue-core/workplans/ISSUE-WP-0002-gitea-pypi-publication.md

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
ISSUE-WP-0002	workplan	Publish issue-core to Gitea PyPI	custodian	issue-core	finished	codex	custodian	2026-05-23	2026-06-05	87a5dcb6-5b2c-4d3f-8d5c-e265889b0fc6

Publish issue-core to Gitea PyPI

issue-core needs a first real Python package release in the Coulomb Gitea package registry so downstream applications can depend on a versioned package instead of a sibling checkout path.

Publish and verify the Gitea PyPI package

id: ISSUE-WP-0002-T01
status: done
priority: high
state_hub_task_id: "f0df7dbc-b55d-4835-a528-f44a329efb0e"

Problem. vergabe-teilnahme and future Railiance S5 apps need issue-core as a normal package dependency. A local dependency such as issue-core @ file:///home/worsch/issue-core makes Docker builds depend on a specific operator workstation and forces non-portable BuildKit named contexts.

Current state. The repo has package release plumbing prepared:

• make package-check builds and validates issue-core==0.2.0.
• make publish-gitea uploads dist/* to the Coulomb Gitea PyPI endpoint.
• .gitea/workflows/publish-python-package.yml can publish on v* tags once package registry secrets exist.
• docs/package-release.md documents local and tag-based publishing.

Resolved blocker. Publishing required a Gitea package username/token with permission to upload to:

https://gitea.coulomb.social/api/packages/coulomb/pypi

The package was published on 2026-06-05 using the operator-provided token from /tmp/gat.tmp; the token value was not written to repo files or command logs.

Implementation steps.

1. Configure Gitea repository or organization secrets: GITEA_PACKAGE_USER and GITEA_PACKAGE_TOKEN.

2. Publish issue-core==0.2.0 either by pushing tag v0.2.0 or by running:

   TWINE_USERNAME=<gitea-user> \
   TWINE_PASSWORD=<package-token> \
   make publish-gitea
   

3. Verify the simple index exposes the package:

   curl -fsS https://gitea.coulomb.social/api/packages/coulomb/pypi/simple/issue-core/
   

4. Verify a clean environment can install the package from the Gitea simple index with credentials injected outside Git.

5. Coordinate with vergabe-teilnahme to regenerate its uv.lock from the published package and confirm its Docker build no longer needs the sibling issue-core checkout.

Done when.

• issue-core==0.2.0 is visible in the Coulomb Gitea PyPI simple index.
• A clean Python environment can install issue-core>=0.2,<0.3 from Gitea.
• The publish workflow has the required secrets and a documented release path.
• The Railiance app deployment blocker can be closed without relying on local path dependencies.

Completed 2026-06-05. Built and checked issue-core==0.2.0, published the wheel and source distribution to the Coulomb Gitea PyPI registry as tegwick through a temporary local Kubernetes port-forward, then exposed the approved public /api/packages ingress route from railiance-forge. The public package-specific simple index returns 200, a clean temporary environment can install issue-core==0.2.0 from Gitea, and vergabe-teilnahme/uv.lock now resolves issue-core from the Gitea registry instead of a sibling checkout.