Public repository: FanHarvard/ldcon. Current version: 0.2.2. No production service is activated by publication.
A PyPI account owner creates a pending publisher at PyPI publishing settings with:
| Project name | ldcon |
|---|---|
| Owner | FanHarvard |
| Repository | ldcon |
| Workflow | release.yml |
| Environment | pypi |
Use the repository's pypi environment to restrict release access. Authentication uses
GitHub OIDC and PyPI Trusted Publishing; no long-lived PyPI API token belongs in this repository.
See the official PyPI setup.
In the virtual environment used for the installation:
python -m pip install --upgrade "ldcon[web,instruments,analysis,agents]" python -m pip check
This selects the latest LDCon release and its declared compatible dependencies. LDCon pins
experiment-core and fanharvard-agentbridge versions, so independent updates to those projects are
adopted when the LDCon dependency pins are updated. For standalone use, update either with
python -m pip install --upgrade experiment-core or
python -m pip install --upgrade fanharvard-agentbridge.
Updating a Python environment does not promote an immutable production release or restart a service. The existing production installation uses its separate deployment and handover procedure.
Edit the public checkout, commit reviewed files and push to main. README and icon changes
are visible on GitHub after the push; they do not require a PyPI version bump. The icon source is
docs/icon.svg; regenerate its PNG with:
rsvg-convert --width 512 --height 512 --output docs/icon.png docs/icon.svg
The public checkout was split from the internal deployment repository. They do not synchronize automatically. Port reviewed source changes and test fixtures explicitly; export deployment configurations as disabled, sanitized examples. Preserve the public packaging metadata and exclude credentials, inboxes and runtime state instead of copying the full deployment directory or its Git history.
Change project.version in pyproject.toml
to a new, unused version. Publish updated experiment-core or agentbridge dependencies first if needed.
When changing the experiment-core pin, update its checkout tag in both CI and release workflows too.
From a development environment with the build, test and role dependencies installed, build into an empty directory so old distributions cannot be uploaded accidentally:
release_dir=$(mktemp -d) python -m build --outdir "$release_dir" python -m twine check --strict "$release_dir"/* python scripts/check_dist.py "$release_dir" python scripts/check_secrets.py python -m pip install --force-reinstall --no-deps "$release_dir"/*.whl python -m pytest -q python -m pip check
Commit and push the reviewed changes. After CI succeeds, create a tag matching the new version
(vX.Y.Z) and publish a GitHub Release for it. That runs release.yml; alternatively
dispatch that workflow at the tag. The workflow checks the tag against package metadata, builds and audits distributions,
tests the wheel, and publishes through the dedicated environment. Do not reuse an uploaded PyPI version.
The CI workflow also checks Python 3.10, 3.12 and 3.13. An existing PyPI release's embedded README
changes only with a new package version; a GitHub push alone does not replace it.
FanHarvard deployment configuration and clone/install procedures live in ldcon-fanharvard. That repository pins published packages; it does not vendor this library. Credential values and runtime state stay local.
Public: source, tests, documentation, MIT license and reviewed examples. Private: credentials, .env/.pypirc files, runtime databases, job logs, agent conversations, approval receipts, local deployment history and live service configuration. New public repositories start from a reviewed snapshot; the internal Git history is not uploaded.
The secret scanner compares findings against individually reviewed non-secret fixtures and code
literals in .secrets.baseline. New findings fail CI. This complements artifact inspection;
it is not a proof that arbitrary future data is safe to publish.