`get-pants.sh` appears to install a broken pants launcher

[bonauer-pf]

Describe the bug
Installing pants via get-pants.sh like this:

$ curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash
Downloading and installing the pants launcher ...
Installed the pants launcher from https://github.com/pantsbuild/scie-pants/releases/latest/download/scie-pants-linux-x86_64 to /home/bonauer/.local/bin/pants

Running `pants` in a Pants-enabled repo will use the version of Pants configured for that repo.
In a repo not yet Pants-enabled, it will prompt you to set up Pants for that repo.

leads to a broken pants installation. No matter which pants command is run, no matter in which folder, it immediately exits with:

$ pants
Killed
Downloading https://github.com/astral-sh/python-build-standalone/releases/download/20260414/cpython-3.14.4%2B20260414-x86_64-unknown-linux-gnu-install_only.tar.gz...
[00:00:00] [------------------------------] 0 B/0 B (eta: 0.0s)
thread 'main' panicked at src/main.rs:73:14:
Failed to write data to output: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Pants version
Doesn't matter, it doesn't get that far

OS
Ubuntu 22.04

Additional info
Minimal reproducer via Docker (installing the 2 dependencies documented in "Prerequisites", but it doesn't change anything):

docker run --rm -it ubuntu:22.04 /bin/bash -c "apt update && apt install -y curl python3-dev python3-distutils && curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash && /root/.local/bin/pants"

[bonauer-pf]

Claude has found this workaround (apparently pinning an older version of scie-pants), which appears to work for 2.31:

curl -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash -s -- -V 0.12.5

Note that this doesn't let you install any pants 2.32 versions!

Claude code's analysis, haven't reviewed too deeply:

Expand for AI analysis

  Root cause                                                                                                                                                            
             
  The panic is not in scie-pants itself — it's in the bundled a-scie/ptex HTTP fetcher, version 1.7.0, in src/main.rs lines 70–75:                                      
   
  fn write(&mut self, data: &[u8]) -> Result<usize, WriteError> {                                                                                                       
      self.output
          .write_all(data)                        
          .expect("Failed to write data to output");   // <-- line 73                                                                                                   
      Ok(data.len())
  }                                                                                                                                                                     
             
  ptex treats EPIPE from the downstream reader as a fatal .expect() panic instead of shutting down gracefully. This .expect() has been present since 2022, so it's a    
  latent bug that something in the new scie-pants release is now exercising.
                                                                                                                                                                        
  Why it only breaks now                                                                                                                                                
                                                  
  get-pants.sh always fetches the latest scie-pants release — there is no version pin by default. The template is:                                                      
             
  https://github.com/pantsbuild/scie-pants/releases/latest/download/scie-pants-${OS}-${ARCH}                                                                            
                                                                                                                                                                        
  Release timeline:                                                                                                                                                     
                                                                                                                                                                        
  ┌─────────┬────────────┬────────────────────────────────────────────────┐                                                                                             
  │ Version │  Released  │                     Notes                      │
  ├─────────┼────────────┼────────────────────────────────────────────────┤
  │ v0.12.5 │ 2025-07-18 │ Last known-good                                │
  ├─────────┼────────────┼────────────────────────────────────────────────┤
  │ v0.13.2 │ 2026-04-22 │ Current latest/download — 9-month jump, broken │                                                                                             
  └─────────┴────────────┴────────────────────────────────────────────────┘                                                                                             
                                                                                                                                                                        
  Suspected triggers in scie-pants v0.13.2                                                                                                                              
                                                  
  Diff: v0.12.5…v0.13.2. Top suspects for newly triggering the latent ptex panic:                                                                                       
             
  1. #524 — Default to 3.14 instead of 3.9 for self-update operations (2026-04-21). All internal lift commands (scie-pants-info, configure, update, install) flipped    
  from #{cpython39:python} → #{cpython314:python}. Changes who consumes ptex output during bootstrap.
  2. #526 — Updated Pex, PBS, and Rust dependencies (2026-04-22). Pex 2.91.2 → 2.92.3, PBS 20260211 → 20260414, Rust 1.94 → 1.95.                                       
  3. #523 — Use musl for default compilation (2026-04-14). Linux scie-pants is now statically linked against musl instead of glibc. (Note: ptex-linux-x86_64 itself is  
  still glibc-linked and shipped upstream by a-scie/ptex.)                                                                                                              
  4. #501 — Run Python in isolated mode (2026-03-16). Adds -I to internal python invocations.                                                                           
  5. #490 — Python 3.14 support + Pex/PBS/Science/Rust bumps (2026-03-09). Cross-cutting bump.                                                                          
                                                                                                                                                                        
  Maintainers appear to already suspect the runtime tools — on the same day v0.13.2 was published they opened scie-pants#529 "Update to latest ptex, jump, science":    
                                                                                                                                                                        
  ▎ I tried doing this as part of the Python 3.14 upgrade, but ran into some [issues]. However, there were a lot of changes in-flight at once. Now that 0.13.2 is out, I
  ▎  can review this in isolation and see if those were red herrings.
                                                                                                                                                                        
  So ptex/jump/science were deliberately not refreshed in 0.13.2 while the surrounding conditions changed.                                                              
                                                  
  Proposed fix                                                                                                                                                          
             
  Two complementary changes:                      

  1. In a-scie/ptex (the actual bug): replace the .expect() on line 73 of src/main.rs with graceful EPIPE handling (treat BrokenPipe as a normal early-exit, not a      
  panic). Ship a new ptex release.
  2. In pantsbuild/scie-pants: cut a 0.13.3 that picks up the fixed ptex (tracked in scie-pants#529), since the current release triggers the latent crash.              
                                                                                                                                                                        
  Workaround for users                                                                                                                                                  
                                                                                                                                                                        
  Pin to the last known-good release:                                                                                                                                   
                                                  
  curl -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash -s -- -V 0.12.5
                                                                                                                                                                        
  For the pantsbuild/actions/init-pants GitHub Action, set SCIE_PANTS_VERSION=0.12.5 — bumping the action pin alone (e.g., to 47212271c5, pantsbuild/actions#46) does   
  not pin scie-pants; the action will still resolve latest and fetch v0.13.2.                                                                                           
                                                                                                                                                                        
  Environment                                     
                                                  
  - Platform: Linux x86_64                                                                                                                                              
  - Installed via: get-pants.sh (default, no -V)
  - scie-pants.bin version: 0.13.2 (strings confirm embedded SCIE_PANTS_VERSION=0.13.2)                                                                                 
  - ptex-linux-x86_64 -V: 1.7.0                                                                                                                                         

[sureshjoshi]

Interesting... I never use that script (or any script that installs that way), so I definitely would not catch something like this.

I'll take a look and see if I can repro.

I quickly read that Claude note and it was largely useless as it was just the changelog of the past few releases.

However, thanks for flagging the problem!

[sureshjoshi]

FWIW coincidentally I updated installation instructions last night with a few more workflows:

#23289

[sureshjoshi]

@bonauer-pf As a sanity, can you run PANTS_BOOTSTRAP_VERSION=report pants ? Just looking at that, I'm guessing it'll point you to 0.13.2, but would be nice to be sure.

I have an idea of the problem, just need to run some tests

[sureshjoshi]

@bonauer-pf I tried your docker repro (but using podman)and it works as expected.

From inside the container, in /root/.local/bin

PANTS_VERSION=2.31.0 ./pants --version
2.31.0

PANTS_VERSION=2.32.0a0 ./pants --version
2.32.0a0

[bonauer-pf]

@bonauer-pf As a sanity, can you run PANTS_BOOTSTRAP_VERSION=report pants ? Just looking at that, I'm guessing it'll point you to 0.13.2, but would be nice to be sure.

It does indeed print 0.13.2.

That's quite odd that it's not reproducible, I can try on other machines and see how portable the failure is. get-pants.sh is the most prominently advertised install method in the docs.

[sureshjoshi]

From the looks of it, the problem seems to not have anything to do with the script, as all that does is download from Github - which all the methods do. It appears to pass.

The problem comes after the script, running the scie-pants binary itself, and that gets run and tested in a lot of ways.

[sureshjoshi]

Did you create this reproducer? docker run --rm -it ubuntu:22.04 /bin/bash -c "apt update && apt install -y curl python3-dev python3-distutils && curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash && /root/.local/bin/pants"

So, running in docker fails with that same error for you? To me, that's a more concerning part, that we can both run the same thing in a container and get different results.

[bonauer-pf]

Yes I agree that is very strange. That's the reproducer I've been running, yes.

Working (pin to 0.12.5):

docker run --rm -it ubuntu:22.04 /bin/bash -c "apt update && apt install -y curl python3-dev python3-distutils && curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash -s -- -V 0.12.5 && PANTS_BOOTSTRAP_VERSION=report /root/.local/bin/pants && /root/.local/bin/pants"

Not working (no version pin):

docker run --rm -it ubuntu:22.04 /bin/bash -c "apt update && apt install -y curl python3-dev python3-distutils && curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash && PANTS_BOOTSTRAP_VERSION=report /root/.local/bin/pants && /root/.local/bin/pants"

I ran docker pull ubuntu:22.04 explicitly and it gave me a newer version of that version tag, not sure if related.

Same problem also in ubuntu:24.04:

docker run --rm -it ubuntu:24.04 /bin/bash -c "apt update && apt install -y curl python3-dev && curl --proto '=https' --tlsv1.2 -fsSL https://static.pantsbuild.org/setup/get-pants.sh | bash && PANTS_BOOTSTRAP_VERSION=report /root/.local/bin/pants && /root/.local/bin/pants"

[bonauer-pf]

I did just try it on a different machine (GitHub codespace) and there it works fine ... so maybe it's just my machine being strange, although I have no explanation for how the problem can bypass Docker isolation.

[sureshjoshi]

Instead of running it as one command - can you hop into the docker container, and try running each of the commands manually? I'm curious if those modes of operation might be the difference

[bonauer-pf]

No difference! I originally discovered it by manually running the commands in our devcontainer. But if it's just on my machine, that's still unfortunate but probably something less urgent, that I need to figure out rather than pants maintainers, thanks anyway for the quick reaction :)

[benjyw]

Hmm, if it can happen to you it can happen to anyone, so it would be great to figure out. If running the same steps in a clean container off the same Docker image doesn't reproduce then... 🤷 I guess if you're mapping host volumes into the container?