The

pants

launcher binary (scie-pants) $RELEASE_TAG is released: * https://github.com/pantsbuild/scie-pants/releases/tag/${RELEASE_TAG} * https://www.pantsbuild.org/docs/installation

Well..... That's embarassing....

also https://www.pantsbuild.org/docs/installation isn't a real link

yeah, that’s been slowly getting updated in a few places - lingered here in the actions. The release tag is using an ENV, but the code itself isn’t in a place that expands the env. Needs to just be the GHA expansion instead… Blah

By the way, what's the best way to check the current installed version of

scie-pants

? Because I used homebrew, doing

ls -l "$(which pants)"

led me to /opt/homebrew/Caskroom/pants/*0.13.2*/scie-pants-macos-aarch64 But I figure there must be a better way that's more generic

I believe it was

PANTS_BOOTSTRAP_VERSION=report pants

aha! that worked

If you run into any problems with this version, please flag them - this is the first version that supports python 3.14 for Pants 2.32 - and all the sanity checks pass, but these updates tend to be a bit more … interesting… than others

A coworker hit this today

brew doctor
Warning: Some directories in the Caskroom do not have valid metadata.
  /opt/homebrew/Caskroom/pants
The following cask cannot be upgraded as-is.
To fix this, run:
  brew reinstall --cask --force pants

brew reinstall --cask --force pants
==> Fetching downloads for: pantsbuild/tap/pants
✔︎ Cask pants (0.13.2)                                                                                                                                                             Verified      8.8MB/  8.8MB
==> Installing Cask pants
==> Linking Binary 'scie-pants-macos-aarch64' to '/opt/homebrew/bin/pants'
==> Unlinking Binary '/opt/homebrew/bin/pants'
==> Purging files for version 0.13.2 of Cask pants
Error: Parameter 'download_path': Expected type T.nilable(Pathname), got type String with value "/opt/homebrew/Caskroom/pan...13.2/scie-pants-macos-aarch64"
Caller: /opt/homebrew/Library/Homebrew/vendor/bundle/ruby/4.0.0/gems/sorbet-runtime-0.6.13133/lib/types/private/methods/call_validation.rb:227
Definition: /opt/homebrew/Library/Homebrew/cask/quarantine.rb:180 (Cask::Quarantine.release!)

which pants
pants not found

Interesting, I wonder if that’s new, or was always there? https://github.com/pantsbuild/homebrew-tap/commit/38f5a5a878acc41cc83de6b836031de8aa93c801 The PR is the same as always

I upgraded via homebrew today and did not have an issue

I wonder if our casks needs to have types updated or something, that error looks like it’s coming from homebrew’s internals (nullable pathname instead of string)

A different coworker yesterday hit the same issue with scie-pants 0.12.5 Their terminal:

➜  data-eng-tools git:(master) brew install pantsbuild/tap/pants
==> Auto-updating Homebrew...
Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or disable with
`$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with `$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).
==> Fetching downloads for: pantsbuild/tap/pants
✔︎ Cask pants (0.12.5)                                                                                                                                                                      Verified      4.3MB/  4.3MB
==> Installing Cask pants
==> Linking Binary 'scie-pants-macos-aarch64' to '/opt/homebrew/bin/pants'
==> Unlinking Binary '/opt/homebrew/bin/pants'
==> Purging files for version 0.12.5 of Cask pants
Error: Parameter 'download_path': Expected type T.nilable(Pathname), got type String with value "/opt/homebrew/Caskroom/pan...12.5/scie-pants-macos-aarch64"
Caller: /opt/homebrew/Library/Homebrew/vendor/bundle/ruby/4.0.0/gems/sorbet-runtime-0.6.13133/lib/types/private/methods/call_validation.rb:227
Definition: /opt/homebrew/Library/Homebrew/cask/quarantine.rb:180 (Cask::Quarantine.release!)

yeah, so I wonder if we’re missing some metadata from our cask - which we’ve likely always been missing.

sure thing

https://github.com/pantsbuild/homebrew-tap/pull/18 Should fix it - I was able to repro the error, then the patch removed the error