templated project version

This commit is contained in:
Iñigo Etxaniz
2026-08-07 16:09:51 +00:00
parent dc3a0f8b0b
commit 64b219fd32
2 changed files with 28 additions and 0 deletions
+1
View File
@@ -3,3 +3,4 @@ build/
*.egg-info/ *.egg-info/
__pycache__/ __pycache__/
*.pyc *.pyc
pyproject.toml
+27
View File
@@ -4,6 +4,33 @@ Python library for scripts running in an i7 job container. It gives a script thr
plant signals (read and write) through the job's sidecar, the customer database through the plant signals (read and write) through the job's sidecar, the customer database through the
db-controller, and millisecond time helpers. db-controller, and millisecond time helpers.
## Versioning and the pyproject template
There is no `pyproject.toml` in this repository. It is generated from
`pyproject.toml.tmpl`, and its version comes from the git tag that triggered the build:
```toml
version = "{{vless .TagName}}"
```
gitea-sidecar renders every `*.tmpl` file in the source to its name minus the suffix before
building the wheel, so a tag of `v0.1.1` produces version `0.1.1``vless` strips the
leading `v`, which git wants and PEP 440 does not. `.TagName` and `.CommitID` are also
available for anything else worth stamping.
The tag is therefore the only place a version is written. Do not add a hardcoded version
back into the template: the build would keep producing that one version, and publishing a
second tag would fail because the package file already exists.
**Building locally** needs the same render step, since the file the build tools look for is
not in the repository:
```bash
sed 's/{{vless .TagName}}/0.0.0.dev0/' pyproject.toml.tmpl > pyproject.toml
```
`pyproject.toml` is gitignored, so a local copy never reaches a build.
## Availability ## Availability
Inside a job container the library is already importable — the scheduler mounts the SDK Inside a job container the library is already importable — the scheduler mounts the SDK