[crowecawcaw]

Fixes: none

Important

Before merging

1. Merge with a merge commit, not squash. The first three commits import the full history of openjd-model-for-python, openjd-sessions-for-python and openjd-cli. The branch-protection ruleset allows only squash merges and requires linear history, so landing this with history needs an admin to bypass the ruleset (or relax it) for this one PR. Squashing works, but the imported history is lost and git blame under python/ points at the squash commit.
2. DCO: 25 of the 776 imported commits have no Signed-off-by (7 model, 10 sessions, 8 cli). They're other people's historical commits, so this PR doesn't rewrite them. A maintainer can mark DCO as passing for them. Every new commit in this PR is signed off.
3. Merging releases openjd-model 0.14.0, openjd-sessions 0.13.1 and openjd-cli 0.7.8 to PyPI. Before merging, set up PyPI trusted publishing and the signing secrets (see "One-time setup" below). Otherwise the PyPI step fails; it can be re-run after the setup.

What was the problem/requirement? (What/Why)

OpenJD development is centered here, but the Python packages live in three other repositories, and each has its own release process. A Rust change that Python users should get takes a chain of releases and PRs:

1. openjd-rs releases the crates.
2. openjd-model-for-python bumps the crates.io pins in its bindings and releases.
3. openjd-sessions-for-python bumps its openjd-model pin and releases.
4. openjd-cli bumps both pins and releases.

The pins drift along the way. On mainline today, openjd-cli still requires openjd-model < 0.12 and openjd-sessions < 0.13, while both are at 0.13.0.

What was the solution? (How)

Move the three Python packages into this repository with their history, build and test them from the Cargo workspace, and release them with the same release-plz Release PR as the crates.

Layout

• python/openjd-model, python/openjd-sessions and python/openjd-cli are the old repositories, imported with git filter-repo:
  • Paths are moved under python/<pkg>/.
  • Old tags are renamed to legacy/<repository>/<version>. Push them separately if you want them upstream (git push origin 'refs/tags/legacy/*'); release-plz ignores them.
  • (#123) PR references are rewritten to OpenJobDescription/<repository>#123, so they don't link to the wrong PRs here.
• openjd-model's PyO3 crate, now openjd-model-py, is a workspace member. It depends on openjd-expr, openjd-model and openjd-sessions by path instead of from crates.io. This removes the bindings' nested Cargo workspace, its Cargo.lock and deny.toml, and the [patch.crates-io] dance.
• openjd-sessions and openjd-cli each get an empty publish = false "release anchor" crate (openjd-sessions-py, openjd-cli-py), so release-plz can version them.
• The python/ crates aren't in default-members, so plain cargo build/cargo test still cover only the Rust crates.

Versions

• Each Python package's version is the version in its Cargo.toml. maturin reads it natively, hatch reads it with a regex, and _version.py reads it back from the installed package's metadata.
• That removes the in-tree PEP 517 backend, generate_version.py, maturin_build.py and the hatch VCS/copy hooks.

Releasing (release-plz.toml, release-plz.yml)

• The Python packages are git_only: their last release comes from a python-<distribution>-v<version> tag, and they're never published to crates.io. release-plz bumps them from conventional commits that touch their directories.
• Cargo dependencies between the packages (bindings → crates, sessions → model, cli → sessions + model) cascade the bumps. A release of openjd-expr, openjd-model or openjd-sessions therefore releases openjd-model too, and then the packages that depend on it, in the same Release PR.
• release-plz doesn't touch pyproject.toml. After it updates the Release PR, the workflow runs the new scripts/sync_python_pins.py on the PR branch to move the pins between the Python packages.
• When a Python tag is created, the workflow:
  • builds the six-platform abi3 openjd-model wheels and sdist, and the openjd-sessions/openjd-cli wheel and sdist, from the tag;
  • PGP-signs every file the way the old repositories did;
  • attaches the files and signatures to the GitHub Release;
  • uploads to PyPI in dependency order.
• The Release PR job now waits for the release job, so it's computed from the tags that job creates (see testing).

CI

• New python.yml runs hatch run lint, hatch build and hatch run test for each package on Linux, Windows and macOS. Each package keeps the Python versions it was tested on before: 3.9–3.14, and 3.9–3.12 for cli.
• Each package is tested against the in-repo versions of the others. The bindings build from the in-repo crates, and the sessions/cli hatch environments install the in-repo packages first.
• The workflow also runs the sessions macOS cross-user tests, the openjd-model THIRD-PARTY-LICENSES.txt check, and sync_python_pins.py --check. It's path-filtered to python/**, crates/openjd-{expr,model,sessions}/**, Cargo files and the workflow itself.
• CodeQL now also analyzes Python, and Dependabot covers the packages' pip requirements.

What is the impact of this change?

• One PR can change a crate and the Python bindings that expose it, and CI tests them together. If a crate change alters what Python users see, the Python tests fail in that PR. This change hit that case twice; see "Is this a breaking change?".
• One Release PR releases everything that changed, and the pins between Python packages stay in step automatically.
• PyPI package names, import names and public APIs are unchanged. Downstream pins keep working.
• After this merges, the three old repositories can be archived with a pointer to python/ here, and their open issues moved with gh issue transfer. Their open PRs are Dependabot bumps and two draft sessions PRs (fix(sessions): prune exited environment variables from WrappedAction.Environment #362, docs(expr): warn that is_relative_to is a lexical prefix test, not containment #367), which would need re-opening here.

One-time setup (also in RELEASING.md)

• On PyPI, add a trusted publisher to each of openjd-model, openjd-sessions and openjd-cli: repository OpenJobDescription/openjd-rs, workflow release-plz.yml, environment release.
• The release environment needs AWS_PGP_KEY_SECRET_ROLE, AWS_PGP_KEY_SECRET and PGP_USER, as the old repositories had.

How was this change tested?

• Locally (macOS arm64, Python 3.14; mypy also on 3.9):
  • openjd-model: 6,323 tests pass.
  • openjd-sessions: 1,015 tests pass.
  • openjd-cli: 318 tests pass, with its pins moved to the 0.13 releases (from < 0.12/< 0.13).
  • hatch run lint is clean for all three.
  • cargo clippy --workspace --all-targets -D warnings, cargo +nightly fmt --check, cargo doc -D warnings and cargo deny check pass.
  • Wheels build from the sdist alone; maturin copies the path-dependency crates into the sdist.
• Fork CI (crowecawcaw/openjd-rs#4):
  • Every ci.yml job passes, including conformance and cross-user on all three OSes, so adding the PyO3 crate to the workspace doesn't affect them.
  • The full Python matrix passes. One Windows/3.12 leg hit a PowerShell-subprocess timeout and passed on re-run; the old model repo's Windows legs flake the same way.
  • The CodeQL check flags only alerts already present in the imported Python code (6 errors, all in files this PR doesn't touch). Every alert is "new" to this repo.
• Release flow, run end to end on the fork's main with a fork-only commit that points the repository guards at the fork, skips the crates, and drops signing and PyPI (which need upstream secrets):
  • The merge created the three python-* tags and GitHub Releases on the merge commit, with the changelog entries as release notes.
  • All six openjd-model wheels, the sdist and the sessions/cli artifacts were built and attached to the releases.
  • Installing the released 0.14.0/0.13.1/0.7.8 wheels into a clean venv works, and openjd check and openjd run succeed.
  • A fix(model): commit produced a Release PR bumping openjd-model to 0.14.1, which cascaded to openjd-sessions 0.13.2 and openjd-cli 0.7.9. The workflow added the "sync Python package pins" commit, and merging that PR released all three.
  • The first fork run found two problems, both fixed here:
    • The Release PR job raced the release job and proposed re-releasing 0.14.0; it now waits for the release job.
    • A duplicated 0.7.1 entry in the sessions changelog stopped release-plz from parsing it, which left the release notes empty.
• Not tested: PGP signing and PyPI upload, which need the upstream secrets and trusted publishers. Those steps mirror the old repositories' reusable_release.yml and the PyPA action, but their first run is the real release.

Was this change documented?

• README has a Python packages section. RELEASING.md describes the Python release flow and one-time setup. AGENTS.md has the package map, CI and release notes.
• python/openjd-model/AGENTS.md is updated for the workspace layout. The package READMEs link to this repository's releases.

Is this a breaking change?

For openjd-model (Python), yes. Building against the in-repo crates picks up openjd-expr 0.11.0, openjd-model 0.12.0 and openjd-sessions 0.8.0. The PyPI 0.13.0 release used 0.10.1, 0.11.0 and 0.7.3. Hence 0.14.0:

• create_job raises ModelValidationError at the binding's template path (e.g. steps[0] -> script -> let[0]), not ExpressionError, when a let binding fails. It also reports every job-creation error at once (feat(model)!: report all job-creation errors at once, with paths #428).
• Expression syntax errors use CPython's wording, e.g. '(' was never closed (fix(expr)!: update ruff parser to 0.16.10, pin exact version, raise MSRV to 1.97 #429).
• Single-letter URI schemes such as C: are treated as filesystem paths (fix(expr): treat single-letter URI schemes as filesystem paths #424).

The five affected tests are updated. openjd-sessions and openjd-cli only move their pins.

Two other changes in the imported code:

• fix(model): mypy failed on mainline with pydantic 2.14 (FieldInfo.annotation is now TypeForm[Any]). This also fails in openjd-model-for-python today.
• scripts/generate_stubs.sh has its paths updated for the new layout. I couldn't run it end to end: building pyo3-stub-gen 0.23 under abi3-py39 fails on mainline too (the /tmp patch the script clones isn't wired in).

Does this change impact security?

It doesn't change runtime code paths. It changes release automation: PyPI uploads move to this repository's release environment via trusted publishing, and PGP signing uses the same secrets as before. Third-party actions are pinned to commit SHAs (PyO3/maturin-action, pypa/gh-action-pypi-publish, aws-actions/configure-aws-credentials).

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[github-advanced-security]

CodeQL found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[github-actions]

Should fix: The Python half of this check depends on whatever PyPI serves at run time, not on anything in the repo. The step installs the wheel with pydantic >= 2.10, < 3 and pyyaml == 6.0.* unpinned, and pip-licenses writes each resolved version into the output (** name; version X).

Failure: pydantic, pydantic-core, typing-extensions, annotated-types or typing-inspection ships a new release. The regenerated file then no longer matches the committed THIRD-PARTY-LICENSES.txt, so the Python package checks job in python.yml fails on every PR that touches python/ or the expr/model/sessions crates, even when the PR doesn't change dependencies.

Fix: resolve the Python section from a pinned constraints/lock file that gets updated together with the committed file. Or compare only package names and licenses, not versions.

[github-actions]

Claude review · advisory

Reviewed ffbc1c5 (full review): 1 finding.

Open: 0 blocking · 1 should-fix · 0 nit. ❌ Address or reply to the open threads.

_{Fix or reply to each thread; the next revision's review re-checks open threads and resolves those it agrees are handled. Resolving a thread yourself also closes it. Later revisions review only what changed.}

[crowecawcaw]

Useful to see we can do it. Not for right now.