Background
The check-environment-yml job in .github/workflows/ci.yml currently does its own pip install pyproject2conda and then invokes pyproject2conda yaml ... with a long argument list that is duplicated from the prek hook config in .pre-commit-config.yaml.
This means we have two pins for the same tool:
.pre-commit-config.yaml → rev: v0.22.1 (GitHub tag, consumed by prek)
.github/workflows/ci.yml → pyproject2conda>=0.22.1,<0.23 (PyPI version, consumed by pip install)
…and two copies of the argument list that have to stay in sync. PR #878 had to add an inline comment reminding future maintainers to bump both in lockstep, which is exactly the smell that motivates this issue.
Proposal
Replace the bespoke pip install + pyproject2conda yaml ... steps with a single call that runs the existing prek hook, e.g.:
- name: Run pyproject2conda via prek
run: prek run pyproject2conda-yaml --all-files
Then diff the regenerated environment.yml against the committed one (the existing tail -n +10 / diff -u step can stay, or be replaced with git diff --exit-code -- environment.yml).
Benefits:
- Single source of truth for the pin (the prek hook
rev).
- Single source of truth for the argument list (the prek hook
args).
- Local
prek run --all-files and CI exercise identical behaviour by construction.
Risks / things to check
- The prek hook writes to the workspace
environment.yml; the current CI step writes to /tmp/environment.generated.yml. The diff strategy needs to flip from "compare two files" to "check git diff after running the hook," which is straightforward but is a behavioural change worth a careful review.
- The existing
tail -n +10 skips a 9-line autogenerated header; we lose that workaround if we use git diff directly. Tracked separately as the header-fragility issue.
- Need to confirm
prek is available on the runner without the j178/prek-action wrapper (or use that action here too).
Acceptance criteria
check-environment-yml job calls a single prek-driven step.
- Bumping the pyproject2conda version requires editing exactly one file (
.pre-commit-config.yaml).
- Job fails the build when
environment.yml is out of sync, the same as today.
Context
Came out of an adversarial review of #878.
Background
The
check-environment-ymljob in.github/workflows/ci.ymlcurrently does its ownpip install pyproject2condaand then invokespyproject2conda yaml ...with a long argument list that is duplicated from the prek hook config in.pre-commit-config.yaml.This means we have two pins for the same tool:
.pre-commit-config.yaml→rev: v0.22.1(GitHub tag, consumed by prek).github/workflows/ci.yml→pyproject2conda>=0.22.1,<0.23(PyPI version, consumed bypip install)…and two copies of the argument list that have to stay in sync. PR #878 had to add an inline comment reminding future maintainers to bump both in lockstep, which is exactly the smell that motivates this issue.
Proposal
Replace the bespoke
pip install+pyproject2conda yaml ...steps with a single call that runs the existing prek hook, e.g.:Then diff the regenerated
environment.ymlagainst the committed one (the existingtail -n +10/diff -ustep can stay, or be replaced withgit diff --exit-code -- environment.yml).Benefits:
rev).args).prek run --all-filesand CI exercise identical behaviour by construction.Risks / things to check
environment.yml; the current CI step writes to/tmp/environment.generated.yml. The diff strategy needs to flip from "compare two files" to "check git diff after running the hook," which is straightforward but is a behavioural change worth a careful review.tail -n +10skips a 9-line autogenerated header; we lose that workaround if we usegit diffdirectly. Tracked separately as the header-fragility issue.prekis available on the runner without thej178/prek-actionwrapper (or use that action here too).Acceptance criteria
check-environment-ymljob calls a single prek-driven step..pre-commit-config.yaml).environment.ymlis out of sync, the same as today.Context
Came out of an adversarial review of #878.