Publish bundled morphir-python 0.0.1 through the FINOS trusted publisher #38

This was generated by AI during triage.

Resolved: 0.0.1 published

morphir-python==0.0.1 is published on PyPI through trusted publishing. The GitHub release is public, and the complete release run succeeded.

PR #39 merged as 50383a03ff01fe4a26054647420f0d0311f82890; its tree matches the validated PR head. The new python-v0.0.1 tag records the corrected bundle, while the failed v0.0.1 tag remains unchanged.

Verified that the PyPI wheel and source archive match the qualified workflow artifacts and GitHub release assets byte-for-byte by SHA256. A clean installation from PyPI imported morphir and morphir_tools, exercised the SDK, passed dependency checks and ran morphir-python ir inspect. No separate morphir distribution was installed.

The matching public project name and standalone bundle resolved the release path. No further PyPI account changes are required for this release.

Current release decision

Publish one morphir-python==0.0.1 distribution containing the core morphir library, Morphir SDK runtime, and CLI. The executable is also morphir-python; Python imports remain morphir and morphir_tools.

The maintainer explicitly selected this bundle in place of the previous two-distribution release and the tentative third-package proposal. It has no dependency on a separate morphir PyPI distribution. PR #39 implements the root package, complete wheel/source archive, renamed CLI, qualification, and single-package publication.

The successful publication confirms this trusted-publisher identity:

No stored token or secret was required; OIDC authentication and the upload both succeeded.

Original failure and evidence

The first attempt used separate morphir==0.0.1 and morphir-tools==0.0.1 distributions. It passed all qualification gates and OIDC authentication, but PyPI rejected the first core upload. Neither package was published.

• Initial setup: PR #37, commit 648d979.
• Original tag: v0.0.1.
• Failed run and core publication job.
• PyPI returned 400 Bad Request: Non-user identities cannot create new projects.
• The remaining response identified a pending-publisher/project-metadata name mismatch. PyPI's troubleshooting guide explains this error.
• The old tools publication and GitHub release jobs were skipped. That tools publisher was never exercised.
• We could not inspect the registered project names without FINOS PyPI account access.

What we configured and tried

1. Used token-free trusted publishing from .github/workflows/release.yml, via pypa/gh-action-pypi-publish@release/v1, with id-token: write limited to publishing.
2. Created GitHub environment pypi, restricted to release tags. It now permits v* and python-v*.
3. Corrected the initial build/output-directory mismatch so qualified artifacts are the artifacts published.
4. Added lint/format/type checks, unit/BDD tests, coverage, strict wheel/source metadata checks, Apache license inclusion, isolated installed-package/CLI checks, known dependency CVE auditing and a permissive license allowlist.
5. The first CVE audit caught CVE-2026-4539 in Pygments 2.19.2. Raised the dependency minimum to 2.20.0 and locked 2.21.0; subsequent CVE/license checks pass.
6. After maintainer approval, merged the initial setup and pushed v0.0.1. OIDC authentication and attestations succeeded, but the old morphir project name did not match the pending publisher.
7. Renamed the CLI distribution and executable to morphir-python, then, with the maintainer's explicit choice, bundled library and CLI into this one distribution. This removes the separate core publisher from the corrected release.
8. Local bundle validation passes 2,062 tests, BDD/type/lint/format checks and 98.50% coverage. The isolated install uses only the bundled wheel and verifies no separate morphir distribution is installed. All library/CLI Python sources are checked in the wheel. Direct and source-archive builds produced identical wheels; CVE/license scans pass.

Account-side questions recorded before publication

• Does the FINOS account own or have a pending publisher for the exact name morphir-python?
• Do the actual owner, repository, workflow and optional environment match the table?
• Did the original attempt create an empty project under a different name? Please inspect before changing anything; we have not deleted or renamed a PyPI project. The troubleshooting guide describes correction of a mistakenly named project.
• Please provide the configured field values or a screenshot with credentials omitted, or confirm the settings are corrected.

Recovery and completion

The original run contains the old two-package layout and must not be retried for the new bundle. After PR #39 passes current-head CI and is merged, publish from the corrected source with a new python-v0.0.1 tag. Leave the original failed v0.0.1 tag at its existing commit.

• Confirm final distribution and command name: morphir-python.
• Select a standalone bundle containing library, SDK and CLI.
• Validate the bundle locally without a separate PyPI core dependency.
• Merge current-head validated PR feat: publish bundled library and CLI as morphir-python #39 and publish morphir-python==0.0.1 through OIDC.
• Verify published file hashes, a clean PyPI installation, library imports, CLI behavior and GitHub release.

Shared tracker: morphir-udu4.