Release and component versions#

Run pyscf2mppt version to see the MPPT release and the actual installed DIAGPT, HEFFSO, pyscf2mppt, CIPSIXX and Caspy components. --version is an alias for the same report, rather than just the Python wrapper’s version.

pyscf2mppt version
pyscf2mppt version --full
pyscf2mppt version --json > installation.json

Read the report#

The first line identifies the MPPT release or development source. Component lines show independent versions and original commits where available. DIAGPT and HEFFSO share the MPPT release numbering. Python package versions and the CIPSIXX version retain their independent numbering.

--full adds resolved paths, artifact hashes and build IDs. JSON includes the same observations, expected component sources and recorded build configuration. No version query imports PySCF or executes a solver, so it remains useful when a native executable cannot load its numerical libraries.

Installation status

Meaning

consistent

Available components match the clean release’s recorded sources

development

Identified components match an untagged or modified source tree

mixed

Observed source identities disagree, or installed Python bytes changed

unverified

At least one required component lacks usable provenance or is absent

Caspy is optional: its absence is reported as not installed. An older native executable without embedded metadata is unknown; it is never assigned the wrapper’s expected version. Rebuild and reinstall that component to identify it.

Source, release and build identity#

Each build preserves the original source commit, exact release tag when present, modified-source flag, component source hashes and a deterministic metadata ID. Native CMake targets retain this record in their executable bytes. Python wheels include _build_info.json and a digest of installed Python code and extensions. Standalone source distributions carry source metadata for rebuilding without Git.

Public snapshots preserve the original source identity from release-manifest.json; their own Git commit is a different publication identity. Runtime inspection reads the installed artifact, never an unrelated checkout in the current working directory. Source-mode inspection is rooted at the imported package’s own source directory.

The same release can have multiple toolchain builds. An artifact SHA-256 identifies exact bytes; a build ID describes recorded build inputs. Neither is a substitute for an environment lock or a guarantee of bitwise-equal numerical results across hardware, BLAS implementations and thread configurations.

Executable selection and managed runs#

The version command resolves cipsixx_select, diagpt and heffso using the same environment overrides as the workflow, then PATH:

  • CIPSIXX_SELECT_EXECUTABLE

  • DIAGPT_EXECUTABLE

  • HEFFSO_EXECUTABLE

Without an input YAML, it reports the default installation. A managed run records the actual executables selected by its YAML or command-line overrides in run.json, under each software record’s provenance field.

New software records include Python package-code hashes as well as interpreter and native-executable hashes. Resume rejects changed captured Python code before reusing its checkpoints; start a new output directory after changing that code. Native stages retain their existing executable-aware checkpoint invalidation. Historical manifests remain readable, with missing provenance explicitly absent. An explicitly selected child interpreter is inspected in its own environment; virtualenv symlinks are preserved. If it cannot return package metadata, the record reports unknown instead of borrowing the parent process’s version.

Automatic release numbers#

After a protected default-branch push passes source checks, source CI allocates one release tag. The default is a patch increment; operators can request minor, major or a release-candidate sequence. A retry reuses the source commit’s existing compatible tag. The public pipeline receives that same tag and does not allocate another version.

Each release has a canonical docs/releases/<tag>.md in its snapshot. Authored notes are preserved; an automatic tag without authored notes receives a deterministic component/version summary covered by the release manifest. The public and source GitLab Releases use those exact same bytes.

Current boundaries#

Native provenance records configured build settings, not a complete inventory of every dynamically loaded library. Keep the resolved environment with the run when exact environmental reproducibility matters. Old standalone Caspy archives without the provenance helper, and Caspy builds under Python below 3.11, report their package version and code hash but cannot provide embedded MPPT provenance.