Skip to content

devops: stripe cli in the Brewfile, on both platforms - #66

Merged
landsman merged 3 commits into
mainfrom
stripe-cli-brewfile
Aug 9, 2026
Merged

devops: stripe cli in the Brewfile, on both platforms#66
landsman merged 3 commits into
mainfrom
stripe-cli-brewfile

Conversation

@landsman

@landsman landsman commented Aug 4, 2026

Copy link
Copy Markdown
Owner

stripe was installed by hand: two mise copies on the Mac, active in no config, and nothing on the Linux boxes. The Brewfile takes it over.

The tap's formula is depends_on :macos, so the if OS.mac? guard applies and Kubuntu gets it from packages.stripe.dev instead — key pinned by fingerprint like every other repo in install-apps.sh. That repo publishes one stable suite for every release rather than one per codename; the new test case asserts the $CODENAME is not pasted in, so a later sweep doing it everywhere gets caught.

Nothing lands in .zshrc

stripe completion prints three steps — create ~/.stripe, add it to fpath, run your own compinit. None is needed once brew owns the install: the formula puts _stripe in share/zsh/site-functions, which brew shellenv already has on fpath, and a second compinit would fight zsh-autocomplete for it. The hand-made ~/.stripe copy is deleted; the Brewfile comment records why the rc files say nothing.

Verified from a real interactive shell — binary at /opt/homebrew/bin/stripe, completion at /opt/homebrew/share/zsh/site-functions/_stripe. make qa passes.

@landsman

landsman commented Aug 8, 2026

Copy link
Copy Markdown
Owner Author

@claude rebase

@claude

claude Bot commented Aug 8, 2026

Copy link
Copy Markdown

Claude finished @landsman's task in 1m 33s —— View job


Tasks

  • Gather context on current PR branch state
  • Determine whether a rebase is something I can perform

Result

I'm unable to perform a git rebase (or any branch operation like merging) on this PR — my tooling is limited to creating and pushing commits on top of the existing branch state, and in this sandbox git fetch against origin is also blocked (network git operations aren't in my allowed tools here), so I can't even pull the latest main locally to attempt one.

If the branch needs to be brought up to date with main, that's something you'll need to do yourself (e.g. git fetch origin && git rebase origin/main and force-push), or ask GitHub to do it via the PR's "Update branch" button if it's offering one.

You can find more information and potential workarounds in the FAQ.

If instead you want me to make a specific code change on this branch, just ask and I can push a regular commit.

Two mise copies on the Mac, active in no config, and nothing on the Linux
boxes. The Brewfile takes it over on both.

The tap's formula is `depends_on :macos`, so the guard applies and Kubuntu
gets it from packages.stripe.dev — the key pinned by fingerprint like every
other repo there, and a suite of `stable` rather than a codename, which the
test asserts so a later sweep does not paste $CODENAME in.

That formula also installs the zsh completion into site-functions, already on
fpath from `brew shellenv`, so the three steps `stripe completion` prints —
a ~/.stripe directory, an fpath line, its own compinit — are all unnecessary
here. The one hand-made copy is deleted, and the Brewfile comment says why the
rc files stay silent about it.
The Brewfile comment said it, but the question gets asked at the fpath
block, and there it looked like an omission. `stripe completion` prints a
~/.stripe recipe that would duplicate the formula's own _stripe and add a
second compinit for zsh-autocomplete to fight; site-functions is already on
fpath from `brew shellenv`. Docker Desktop keeps its line because it is not
a brew install, which is now the stated rule rather than a coincidence.
…s on

Every completion in the Brewfile reaches the shell one way — the formula
drops _name into $HOMEBREW_PREFIX/share/zsh/site-functions and `brew
shellenv` in .zshrc puts that on fpath. It is the step of the install nobody
sees, and it fails silently: move the shellenv line below the completion
block and every brew completion goes quiet with no error.

So it is asserted now, stripe as the worked example. bin-test's os/*/*.test.sh
glob picks it up, so there is no Makefile change.

Both failure modes are checked against a broken copy of the rc rather than
assumed: the deleted shellenv line, and someone following the recipe `stripe
completion` prints (a ~/.stripe on fpath and a second compinit). The first
draft passed the deleted-shellenv case — FPATH and HOMEBREW_PREFIX are
exported by shellenv, so a run from a configured shell inherits the entry it
means to prove. Both are scrubbed, and $HOME is redirected at a temp dir, which
also keeps the run from writing a compdump into the real one.
@landsman
landsman force-pushed the stripe-cli-brewfile branch from 312d422 to cc4a56c Compare August 9, 2026 13:31
@landsman
landsman merged commit 75db4d2 into main Aug 9, 2026
3 checks passed
@landsman
landsman deleted the stripe-cli-brewfile branch August 9, 2026 13:32
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