Skip to content

fix(poiesis-printer-chromium): align which to 8, matching the rest of the workspace - #6964

Merged
forkwright merged 1 commit into
mainfrom
chore/which-8-align
Aug 24, 2026
Merged

fix(poiesis-printer-chromium): align which to 8, matching the rest of the workspace#6964
forkwright merged 1 commit into
mainfrom
chore/which-8-align

Conversation

@forkwright

Copy link
Copy Markdown
Owner

What

crates/poiesis/printer-chromium/Cargo.toml pinned which = "=7.0.3" while crates/organon/Cargo.toml and crates/poiesis/doc/Cargo.toml already carried which = "8" -- the same workspace resolving two majors of the same crate. Moved printer-chromium to which = "8".

Why exact, and why removing it is safe

Traced the pin to its origin: commit bd4e29e3b ("add chromium CDP printer for HTML-to-PDF conversion"), which introduced it on the same line-style as chromiumoxide = "=0.7.0" in the same diff. Neither the commit message nor any comment near the line gives a reason specific to which -- no RUSTSEC ignore references it, no deny.toml/audit.toml entry mentions it. Reads as inherited from chromiumoxide's own exact-pin convention rather than a deliberate constraint on which. With no recorded rationale, matching the rest of the workspace (organon, poiesis/doc) is the right call.

API breakage

None. printer-chromium's only which call site (which::which(candidate) in chromium_impl.rs, used for Chromium binary discovery) is byte-identical in shape to organon's existing which-8 call site, which already compiles clean.

Verified

  • cargo check -p poiesis-printer-chromium --features chromium (isolated CARGO_TARGET_DIR) -> Finished, exit 0, resolves which v8.0.5.
  • Cargo.lock diff: single which entry at 8.0.5, all four dependents point at it, duplicate which 7.0.3 entry and its orphaned which-7-only transitive dep env_home are gone.
  • poiesis/doc confirmed already on which = "8" before this change -- printer-chromium was the sole outlier.

Not run: full workspace build/test (out of scope for a single-crate dependency bump on a shared box; scoped cargo check is the appropriate verification per the box's build constraints).

… the workspace

printer-chromium pinned `which = "=7.0.3"` while organon and poiesis/doc
already depended on `which = "8"`, splitting the workspace across two
majors of the same crate and duplicating it (plus its which-7-only
transitive dep env_home) in Cargo.lock.

git blame traces the exact pin to the crate's initial commit
(bd4e29e, "add chromium CDP printer for HTML-to-PDF conversion"),
introduced on the same line-style as `chromiumoxide = "=0.7.0"`. Neither
the commit message nor any nearby comment gives a reason specific to
`which` (no RUSTSEC ignore, no deny.toml/audit.toml entry references it)
-- the exactness reads as inherited from chromiumoxide's own pin rather
than a deliberate constraint on which itself. With no recorded reason to
keep it exact, move to the unpinned "8" that already matches organon and
poiesis/doc.

which::which()'s signature is unchanged across the bump: printer-chromium's
only call site is byte-identical in shape to organon's existing which-8
call site, and `cargo check -p poiesis-printer-chromium --features
chromium` resolves which 8.0.5 clean with no warnings.
@sonarqubecloud

Copy link
Copy Markdown

@forkwright
forkwright merged commit f061463 into main Aug 24, 2026
40 checks passed
@forkwright
forkwright deleted the chore/which-8-align branch August 24, 2026 19:28
forkwright pushed a commit that referenced this pull request Aug 25, 2026
🤖 I have created a release *beep* *boop*
---


##
[0.42.1](v0.42.0...v0.42.1)
(2026-08-25)


### Bug Fixes

* **poiesis-printer-chromium:** align which to 8, matching the rest of
the workspace
([#6964](#6964))
([f061463](f061463))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant