ci: pin pyproject2conda==0.22.1 to work around 0.23.0 regression

[drbenvincent]

Summary

The check-environment-yml CI job has been failing on every PR opened since 2026-04-29 with:

File ".../pyproject2conda/_normalized_requirements.py", line 115, in _iter_parts
    if self.channel:
       ^^^^^^^^^^^^
AttributeError: 'CondaRequirement' object has no attribute 'channel'

Root cause

The job does pip install pyproject2conda with no version constraint (ci.yml:51-52), so each CI run grabs whatever is latest on PyPI.

pyproject2conda 0.23.0 was published to PyPI on 2026-04-29 and contains a regression where CondaRequirement instances no longer expose the channel attribute that _iter_parts() still tries to read. This is hit during __hash__ of any conda requirement, so the tool blows up immediately when called with the args our workflow uses.

The local prek hook in .pre-commit-config.yaml is already pinned to v0.22.1 (the last good release), so local prek run --all-files is unaffected — only CI breaks.

Filed upstream as usnistgov/pyproject2conda#94.

Fix

Pin the CI pip install to >=0.22.1,<0.23 so it tracks the same 0.22.x line as the local prek hook (rev: v0.22.1) while still allowing a hypothetical 0.22.x patch backport to ship without a workflow edit. Added an inline comment explaining the failure mode so future bumps remember to lift CI and the prek hook in lockstep.

Why pin instead of work around?

The traceback lands in CondaRequirement.__hash__ → _iter_parts(), which is invoked unconditionally as soon as pyproject2conda materialises any conda requirement. There is no plausible CLI flag, env extra, or pyproject.toml shape change that avoids that code path while still producing a usable conda yaml — the broken attribute access fires before any of our arguments matter. Pinning is therefore the right lever; alternative workarounds were not pursued because they cannot exist for this failure mode.

Evidence this is environmental, not PR-specific

• PR Docs: Add Synthetic Control sensitivity checks walkthrough #871 (docs/789-sc-sensitivity-walkthrough) has check-environment-yml failing despite touching only a single .ipynb file (no pyproject.toml or environment.yml changes).
• PR Add RD/RKink sensitivity-checks walkthrough #872's last successful check-environment-yml run was on 2026-04-28 — it picked up pyproject2conda 0.22.1 before 0.23.0 was published.
• All other open PRs that haven't been pushed to since 2026-04-29 still show the check as green.

Test plan

• CI check-environment-yml job passes on this PR.
• After merge, rebase Docs: Add Synthetic Control sensitivity checks walkthrough #871 onto main and confirm check-environment-yml goes green there too.

Follow-up

When pyproject2conda ships a fixed release, bump both .pre-commit-config.yaml (rev: v0.22.1 → newer) and .github/workflows/ci.yml (the version range → newer) together — or, preferably, merge #882 first so there is only one place to bump.

Tracked separately:

• Upstream regression report: usnistgov/pyproject2conda#94
• Consolidating the CI invocation through the prek hook (removes the dual-pin surface): Consolidate CI pyproject2conda invocation through the prek hook #879, implemented in ci: consolidate pyproject2conda invocation through the prek hook #882
• Hardening the tail -n +10 header comparison in this same job: Fragile header-skip in check-environment-yml diff comparison #880
• Auditing pip-install steps in CI for consistent supply-chain pinning: Audit pip-install steps in CI for consistent supply-chain pinning #881

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.60%. Comparing base (deb8774) to head (0de4a8e).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #878   +/-   ##
=======================================
  Coverage   94.60%   94.60%           
=======================================
  Files          80       80           
  Lines       12764    12764           
  Branches      770      770           
=======================================
  Hits        12076    12076           
  Misses        485      485           
  Partials      203      203           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[read-the-docs-community]

Documentation build overview

📚 causalpy | 🛠️ Build #32484936 | 📁 Comparing 0de4a8e against latest (deb8774)

  🔍 Preview build  

1 file changed

± 404.html

[drbenvincent]

Updated this PR off the back of an adversarial review. Two changes in 0de4a8e:

1. Widened the pin from ==0.22.1 to >=0.22.1,<0.23. The strict equality was unnecessarily rigid — if upstream ever ships a 0.22.2 patch backport (e.g. a security fix), the range pin picks it up automatically while still excluding the broken 0.23.x line. The lower bound matches the prek hook's rev: v0.22.1; the upper bound is the meaningful one.

2. Dropped the hardcoded release date from the inline comment (released 2026-04-29). The version identifier 0.23.0 is the durable reference and git blame recovers the date if anyone needs it. Replaced that line with a more useful description of the failure mode (_iter_parts → __hash__) so future readers can tell at a glance whether a new release has actually fixed the right thing.

Also added a "Why pin instead of work around?" section to the PR body. Short version: the regression is in CondaRequirement.__hash__, which fires as soon as conda requirements are processed — there is no CLI flag or pyproject.toml shape that avoids that code path, so pinning is the only real lever and alternative workarounds were not pursued.

Follow-ups that came out of the review have been filed as separate issues / will be opened as a follow-up PR; links will be added to the PR body's "Follow-up" section as they land.